Просто думаю насчет целесообразности появления еще одного фреймворка, против целесообразности расширения существующих )
Это только время покажет…
Тогда не лучше ли свои наработки реализовать на базе существующего фреймворка? В виде форка или плагина
Нет не лучше, если брать уже готовый «продукт» и создавать на базе него свой продукт, то это в конечном результате может негативно сказаться на производительности за счет использования лишних абстрактных слоев кода и тогда остается один выход — переписывать все заново.
Ну и кроме того. Блоки в зависимости от страницы могут меняться. Гораздо лучше их контролировать на стороне сервера, и использовать кэширование.
Я бы был рад, если бы был удобный плагин, в виде к примеру автоматического dispatcher'а.
Объясню более конкретно. Мы храним «активные» DOM-элементы (то есть те, которые должны выполнять какие-то события). Пусть, это будут даже объекты того же jQuery. Мы просто где-то пишем функции для событий. А в одном месте, объявляем кортежи (элемент, событие, callback). И dispatcher автоматически инициализирует callbacks. То есть некая реализация синтаксического сахара, если можно так сказать. Но это явно не тянет на фреймворк с серверной стороной )
Ну и кроме того. Блоки в зависимости от страницы могут меняться. Гораздо лучше их контролировать на стороне сервера, и использовать кэширование.
Нет, лучше их контролировать на клиенте, так у сервера остается менше задач, о которых иму надо заботится. По поводу кэширования, лучше наверное пример для наглядности: есть блок «body», в котором должна выводится фраза «hello world», эти данные запрашиваются у сервера, а сервере уже решается взять данные из кэша или БД(например), то есть запрос происходит в любом случае.
На счет плагина, не знаю, при разработке какого либо приложения с таким плагином придется писать очень много лишнего кода, когда все поддерживается из коробки, это существенно упрощает решение задач.
(подчеркиваю к библиотеке JS)
Дело в том что js библиотек много, и не все в своей разработке использую jQuery, а писать плагин под каждую библиотеку — это лишняя работа.
framework — можно перевести как «рабочие рамки», выходит так, что тебе не нравятся мною предложенные «рамки».
Первое, flash — для флеша можно написать порт клиентской стороны, это большого труда не составит, в будущем скорее всего так и будет сделано.
Второе, серверная сторона — такое разнообразие реализаций на различных языках не будет, наиболее вероятные языки для написания порта node.js(javascript) или python.
А на счет свободы, то расширить существующий php framework, какими либо php классами ни составит никакого труда, как это сделать я опишу в документации(это не код писать, гораздо хуже выходит)
Часть кода которая должна находится на клиенте, пишется на java а потом транслируется в javascript и далее передается на клиент. В моем случае часть кода, который должен работать на клиенте изначально написана на javascript, и насколько мне известно, на данный момент программная оптимизация кода во много раз уступает человеческой.
Пожалуй особенность моего фреймворка является плагин w.area.js. HTML-страницу условно можно разбить на несколько областей, например шапка, подвал, rightbar, контент, так вот когда человек кликает по ссылке, то всю страницу перезагружать не нужно, а нужно перезагрузить одну из областей(или несколько связанных областей), этим и занимается плагин w.area.js. Это чем то похоже на страницу построенную на фреймах, но гораздо удобнее и функциональней, а весь остальной код фреймворка «заточен» под этот плагин.
ставка делалась простоту и доступность при создании web-приложений
gwt, vaadin, cappuccino
в моем фрамеворке не происходит перемешивание кода, js — отвечает за логику, а php только за чтение/запись данных(на практике еще сериализацию, сессии и авторизацию)
ну, если производительности php будет мало, серверную часть перепишу на каком либо другом языке(скорей всего на javascript), программы которого работают через fastcgi интерфейс
в начале разработки в ff 3.x не работали некоторые функции корректно, поэтому было такое требование к браузеру, но на данный момент скрипты корректно работают в ff 3.6.xx
Нет не лучше, если брать уже готовый «продукт» и создавать на базе него свой продукт, то это в конечном результате может негативно сказаться на производительности за счет использования лишних абстрактных слоев кода и тогда остается один выход — переписывать все заново.
Нет, лучше их контролировать на клиенте, так у сервера остается менше задач, о которых иму надо заботится. По поводу кэширования, лучше наверное пример для наглядности: есть блок «body», в котором должна выводится фраза «hello world», эти данные запрашиваются у сервера, а сервере уже решается взять данные из кэша или БД(например), то есть запрос происходит в любом случае.
На счет плагина, не знаю, при разработке какого либо приложения с таким плагином придется писать очень много лишнего кода, когда все поддерживается из коробки, это существенно упрощает решение задач.
Дело в том что js библиотек много, и не все в своей разработке использую jQuery, а писать плагин под каждую библиотеку — это лишняя работа.
Первое, flash — для флеша можно написать порт клиентской стороны, это большого труда не составит, в будущем скорее всего так и будет сделано.
Второе, серверная сторона — такое разнообразие реализаций на различных языках не будет, наиболее вероятные языки для написания порта node.js(javascript) или python.
А на счет свободы, то расширить существующий php framework, какими либо php классами ни составит никакого труда, как это сделать я опишу в документации(это не код писать, гораздо хуже выходит)
Что такое w framework можешь почитать , в 10 строк объяснить это у меня не выходит.
Пожалуй особенность моего фреймворка является плагин w.area.js. HTML-страницу условно можно разбить на несколько областей, например шапка, подвал, rightbar, контент, так вот когда человек кликает по ссылке, то всю страницу перезагружать не нужно, а нужно перезагрузить одну из областей(или несколько связанных областей), этим и занимается плагин w.area.js. Это чем то похоже на страницу построенную на фреймах, но гораздо удобнее и функциональней, а весь остальной код фреймворка «заточен» под этот плагин.
ставка делалась простоту и доступность при создании web-приложений
в моем фрамеворке не происходит перемешивание кода, js — отвечает за логику, а php только за чтение/запись данных(на практике еще сериализацию, сессии и авторизацию)
ну, если производительности php будет мало, серверную часть перепишу на каком либо другом языке(скорей всего на javascript), программы которого работают через fastcgi интерфейс
что именно не увидел? Там по адресу есть картинка с большой w в формате *.svg и три ссылки.
не понял суть вопроса