Для профилирования очень рекомендую xdebug :) Это намного удобнее, чем ручные измерения. Получаются прекрасные и информативные отчёты, какие методы и функции сколько чего жрут:
А с идеологической точки зрения, всё же, рекомендую во-первых, буферирование выхода, во-вторых, переход к идеологии «в проекте должно быть только одно echo — вывод результата».
Ну и сам сайт хорошо бы проектировать так, чтобы динамика отдавалась небольшими кусками. А всё толстое — статикой или иными решениями, не PHP. Например, тем же mod_cml на lighttpd.
Неужели Вы никогда не слышали о серверном PHP XSLT-процессинге и клиентах, не поддерживающих XSLT? :)
Я думал, что Вас интересует банальная XSLT-шаблонизация, разбираемая сервером — это очень распространённая тема в PHP-сообществе.
В общем, в любом случае тут без размножения сущности не обойтись. Придётся делать прослойку, извлекающую нужные данные для формирования DOM-дерева.
>А правки во View по определению не могут «тянут за собой правки в Code» (в данном случае Вы имеете ввиду Controller я так понимаю)
Да, оговорка. Имелся в виду Controller. А так — поясню на примере. Предположим, у нас сложный объект с десятками полей. На конкретной странице все эти поля не нужны, значит код формирует DOM-дерево с только актуальными параметрами. Которыми уже и насыщается XSLT.
Всё хорошо, но завтра дизайнеру понадобится вывести другое поле. И в случае его работы с шаблонами на Smarty или PHP он поменяет только View. Шаблон. Обращаясь к новым полям. В случае XSLT ему придётся правитьи шаблон, и код, вытаскивающий для него данные.
Такую, достаточно распространённую ситуацию я и имел в виду. Я в своей практике обычно редко подпускаю дизайнеров к коду. И не из соображений безопасности. Они его просто боятся :D
>Возможно, Вам будет привычнее формировать готовый HTML на стороне сервера
Да, я сперва Ваш вопрос так и понял. Но, поскольку без формирования промежуточного DOM-дерева не обойтись, то разницы уже, формировать всё на сервере или отдавать поддерживающему клиенту — нет.
А задачу я решил грубо и не особо красиво, но как придумалось навскидку — вместе с системными данными шаблона передаю массив со списками полей, которые необходимо извлекать из передаваемых объектов для формирования DOM-дерева.
Т.е. к
$data = array(
'users' => objects_array('forum_user', array('order' => '-reputation', 'limit' => 10)),
);
Я не говорю, что в ZF чего-то сделать нельзя. Просто он громоздкий и неудобный. На те же действия требует в разЫ больше писанины.
Кроме того, повторю, что у меня просто выше уровень абстракции. Вещи, которыми занимается Zend (о Simfony речи вообще не идёт) реализуются у меня относительно небольшими дописываемыми модулями. При желании можно хоть эмулятор Zend-фреймворка на моём написать :) И принимать/понимать его расширения.
Но, боюсь, на словах этого не обяснить, и Вам придётся (если, конечно, Вами движет реальный интерес к сравнению, а не нонконформизм или простое желание задавить новичка в вашей тусовке), ждать, пока я оформлю комплект простых примеров.
>А вообще, реализацию CMF без использования других фреймворком или их отдельных компонентов, ну например того же Zend, я считаю велосипедоводством.
Уже писал, что мой фреймворк очень легко цепляется к чужим системам. Многократно проверено на практике :) Это и использование чужих механизмов (например, расширения MediaWiki, а форум мой до сих пор наполовину состоит из модифицированного punBB), и переписывание на данный фреймворк ряда коммерческих сторонних сайтов с готовыми и активно используемыми движками. Там происходила постепенная и незаметная подмена старого кода моим. Интеграция бывала совершенно незаметной со стороны готового продукта :)
>Ну не нравица вам реализация MVC у Zend, ну дополните ее или перепишите полностью.
Зачем, если у меня уровень абстракции выше (т.е. хочу с MVC пишу, хочу — без. Хочу, MVC на XSL сделаю, захочу — на шаблонах какого-нибудь iPB)?
И что касается велосипедостроительства… Тут ещё зачастую вопрос чей велосипед был раньше :D
Эти же механизмы у меня будут и на Java реализованы :) Хотя это несколько позже и без привязки к Web, в другом проекте. Основные принципы легко ложатся почти на любую платформу, лишь бы там были механизмы рефлексии.
>скоро разница исчезнет между серверной частью и клиентской.
В системе всё есть. Постраничный список делается введением двух параметров в запрос массива объектов (номер страницы и число элементов на страницу) и вызовом одного метода из шаблона.
(опционально во втором случае могут быть аргументы, указывающие на стили и варианты отображения).
>Врятли XML можно назвать технологией и особенно механизмом, но мысль понял.
XML — это именно механизм хранения информации (данные или шаблоны) и технологии для работы с этим механизмом :)
В общем, как обещал, вечером покурю над XSLT (никогда не работал с ним) и для демонстрации расширения сделаю модуль XSLT-шаблонов тела страницы. Насколько я понимаю, основной затык у меня будет с конвертированием ассоциативного массива в DOM, понятный XSLT.
>Или это я Вас не так понял.
Видимо, мы где-то друг друга не поняли :) Ладно, если тема будет развиваться, то мы ещё обсудим недопонятое на более конкретных примерах :)
>Грубо говоря вызов метода из скрипта вида (или шаблона или лейаута).
Из Smarty-шаблона свободно вызываются любые методы объекта. Из PHP-шаблона — тем более :)
В общем, повторюсь, что шаблонный механизм — это именно сменный механизм. При желании и тот же Zend можно подключить, уровень абстракции у меня очень высокий :)
>именно. придуманные десяток лет назад стандарты и направления — уже давно не отвечают текущим требованиям по скорости разработке, удобству поддержки и самое главное скорости изменения.
Что Вы предлагаете взамен? :)
>коро они загнутся. нужно не идти за модой а делать то что нужно.
Что нужно делать сегодня по-Вашему?
>по документации посоветовал бы побольше примеров. а именно Hello world. так легче остальным будет понять.
Будет целая серия. А так — неужели HelloWorld в виде вывода конкретного объекта по второй ссылке в первом сообщени — это черезчур сложно? :) Я просто не представляю, как можно хоть что-то конкретное сделать ещё проще :D
>а в документации на поверхности — побольше примеров от простых к сложным. и постарайтесь чтобы их исполнение — было действительно простым.)))
>Неплохо было бы оширную статью написать, с диаграммами, с примерами.
Это пока именно попытка узнать, что людям нужно в документации в первую очередь. Документация для такого проекта не пишется на коленке за несколько вечеров, увы.
>P.S. Неплохо было бы еще и дизайнера нанять ;)
Да где ж взять дизайнера, готового работать просто так. А проект — некоммерческий, денег он не приносит и не будет приносить :)
>P.S.S. А система случайно не новый римейк «Атаки клонов»?
Не слышал про такую (ну, кроме одноимённого фильма :) )
Система имеет довольно глубокие корни, восходя ещё к офлайновой системе на Форте в конце 1990-х гг. Лет пять назад понемногу доросла до микроядерной системы на PHP. Одно из расширений микроядра, объектное, оказалось столь удобным, что понемногу весь остальной код был снесён, а объектное расширение перенесено на уровень ядра. В таком виде система стала уже фреймворком, где-то около пары лет развивается на весьма сложных задачах и, к моему удивлению, за этот срок ни разу не натыкался на идеологические ограничения скелета фреймворка. Т.е., похоже, базис у него заложен верный :D
>Эх, недоработали вы пока вывод списка своих объектов.
А точнее?
>Такое уже на XML давно делают
В этом фреймворке нет жёсткой привязки к механизмам и технологиям. Если Вы имели в виду использование XML в роли шаблонов, то пишется соответствующий render-engine легко и быстро. Просто лично мне намного удобнее использовать Smarty. Но в заметках по ссылке особо отмечено, что движков отображения может быть сколько угодно и подменяться они могут даже в рамках одного объекта в зависимости от его внутренних условий :)
Пожалуй, вечером сяду и напишу Вам render_xml, просто как демонстрацию расширения функционала системы :)
>людям не удобно работать с вызовами функций, с вложенными массивами да и вообще с кодом
То есть букву «C» в MVC уже отменили? :) Или я Вас не понял? Как вы представляете работу системы без кода? :)
>И вообще, посоветовал бы Вам, выдрать этот помощник вида для вывода списка объектов
Честно говоря я не понимаю, о чём Вы ведёте речь :)
>и запихнуть его в что нибудь более распространенное, скажим в Zend Framework или Symfony
И Zend и Symfony не имеют нужной мне гибкости и расширяемости. А у последнего ещё и с MVC полный караул. По крайней мере уровня examples мне хватило :) Мешать шаблоны и PHP-код — не лучшая идея. Кстати, у меня тоже так можно. Но не нужно.
>кода писать приходится (судя по тому описанию которое вы выложили)
Вы, видимо, очень невнимательно читали пример.
Создание полностью развёрнутого MVC-модуля, это:
— 1 строка подключения модуля к ссылке
— 4 строки описания класса в две функции
— 2 строки в шаблоне
Это — много? Можно примеры, где то же самое будет писаться компактнее? :D
>а идеологическое развитие застряло где то в 2003-2004 годах
Поясните Вашу мысль. Что конкретно не нравится в идеологии моей системы? Или MVC, модульность и ORM сегодня уже идеологически не верны? :D Тогда, наверное, да, я где-то застрял. В общем, поясните.
>да и хорошая система на самом деле не должна быть огромная.
Система по сути микроядерная. И её ядро очень компактно. «Огромна» она — в плане количества модулей и расширений. Это, как бы, две большие разницы…
>а документация должна быть маленькая и понятная
Этот постинг и был написан с целью выяснения, на что при составлении документации обращать внимание. Очень, знаете ли, трудно писать документацию на то, чем пользуешься много лет. Если Вы невнимательно читали первый постинг, процитирую главное оттуда: «сразу трудно решить, какие направления в документации оформлять в первую очередь».
Я пришёл не столько рекламировать фреймворк, сколько просить помочь с мыслями по составлению документации. А в результате огрёб массу минусов, так что, не могу даже в свой блог написать более детальный и объясняющий постинг :)
Да, моё упущение. Фреймворк, как и большинство аналогичных решений на PHP, предназначен для разработки Web-сайтов под LAMP :)
(К сожалению, как я понял, из-за получения сразу нескольких минусов в комментариях, не могу в блог написать отдельный более детальный постинг.)
А так:
Характерные черты:
— Полный MVC
— Предельная модульность
— Высокая скорость обработки
— Простое использование статического кеширования
— Легко расширяемый ORM на разных носителях данных
— Очень лёгкая интеграция с любыми другими системами (ORM легко перенастраивается на сторонние источники данных)
В общем на те вещи, которые вручную писались сутками, на том же Symfony пишутся за часы, у меня нередко можно сделать за минуты. При этом результат высоко стабилен, хорошо защищённый от side-effects, легко рефакторится. Чтобы понять, что же делалось в том или ином модуле год спустя, требуются подчас считанные минуты. Это тоже большая редкость в сегодняшних системах :)
Да нет, не бессмысленно. Если ты что-то можешь представить, пусть даже упрощая — ты это легче запомнишь и будешь свободнее этим оперировать. Куда проще расчитать, например, туннелирование, если ты представляешь, что стоит за соответствующими формулами, а не воспринимаешь их как простой набор символов.
Досмотрел ролик только для половины. Мультипликация — это неинтересно :) Неубедительно для современного школьника. Нарисовать можно что угодно. Показали бы реальные опыты — было бы хотя бы интересно посмотреть :)
…
По упомянутому же «Секрету» (ага, у меня жена увлеклась этими новомодными веяниям) — увы, ничего хорошего сказать не могу. Модная во многие времена попытка объяснить чистую фантазию автора научными терминами, с которыми авторы знакомы понаслышке из бедного американского общего образования :)
У любого, знакомого с физикой хотя бы на уровне советского общего образования вызывает в лучшем случае улыбку, в худшем — огорчение от того, куда катится этот мир…
Так можно было просто написать: «профилирование с помощью xdebug показало, что echo выполняет N секунд» :)
www.xdebug.org/docs/profiler
А с идеологической точки зрения, всё же, рекомендую во-первых, буферирование выхода, во-вторых, переход к идеологии «в проекте должно быть только одно echo — вывод результата».
Ну и сам сайт хорошо бы проектировать так, чтобы динамика отдавалась небольшими кусками. А всё толстое — статикой или иными решениями, не PHP. Например, тем же mod_cml на lighttpd.
Я думал, что Вас интересует банальная XSLT-шаблонизация, разбираемая сервером — это очень распространённая тема в PHP-сообществе.
В общем, в любом случае тут без размножения сущности не обойтись. Придётся делать прослойку, извлекающую нужные данные для формирования DOM-дерева.
>А правки во View по определению не могут «тянут за собой правки в Code» (в данном случае Вы имеете ввиду Controller я так понимаю)
Да, оговорка. Имелся в виду Controller. А так — поясню на примере. Предположим, у нас сложный объект с десятками полей. На конкретной странице все эти поля не нужны, значит код формирует DOM-дерево с только актуальными параметрами. Которыми уже и насыщается XSLT.
Всё хорошо, но завтра дизайнеру понадобится вывести другое поле. И в случае его работы с шаблонами на Smarty или PHP он поменяет только View. Шаблон. Обращаясь к новым полям. В случае XSLT ему придётся правитьи шаблон, и код, вытаскивающий для него данные.
Такую, достаточно распространённую ситуацию я и имел в виду. Я в своей практике обычно редко подпускаю дизайнеров к коду. И не из соображений безопасности. Они его просто боятся :D
>Возможно, Вам будет привычнее формировать готовый HTML на стороне сервера
Да, я сперва Ваш вопрос так и понял. Но, поскольку без формирования промежуточного DOM-дерева не обойтись, то разницы уже, формировать всё на сервере или отдавать поддерживающему клиенту — нет.
А задачу я решил грубо и не особо красиво, но как придумалось навскидку — вместе с системными данными шаблона передаю массив со списками полей, которые необходимо извлекать из передаваемых объектов для формирования DOM-дерева.
Т.е. к
$data = array(
'users' => objects_array('forum_user', array('order' => '-reputation', 'limit' => 10)),
);
дописываем ещё
'xml_fields' => array('users' => 'title reputation'),
И формирователь дерева создаст дерево только с нужными параметрами.
…
Затык пока случился только на формировании DOM-дерева из ассоциативного массива. В частности — на вложенных простых массивах.
Так что за вечер задачу решить не удалось, но не из-за ограничений фреймворка :)
Кроме того, повторю, что у меня просто выше уровень абстракции. Вещи, которыми занимается Zend (о Simfony речи вообще не идёт) реализуются у меня относительно небольшими дописываемыми модулями. При желании можно хоть эмулятор Zend-фреймворка на моём написать :) И принимать/понимать его расширения.
Но, боюсь, на словах этого не обяснить, и Вам придётся (если, конечно, Вами движет реальный интерес к сравнению, а не нонконформизм или простое желание задавить новичка в вашей тусовке), ждать, пока я оформлю комплект простых примеров.
Планирую по GPL, только не задумывался ещё, v2 или v3.
В принципе, ничего сложного, всё в единицы строк укладывается, но есть одна принципиальная проблема.
Если я правильно понял, то XSLT-процессор принимает данные только в виде DOM. И передать PHP-объект туда нельзя в принципе.
Значит, все нужные в шаблоне данные нужно извлекать из объектов дополнительным действием.
Т.е. получаем, скажем, массив объектов, а потом трансформируем его в DOM-объект, указывая нужные аргументы в коде.
Некрасиво + правки во View тянут за собой правки в Code.
Есть мысли, как этого избежать?
Уже писал, что мой фреймворк очень легко цепляется к чужим системам. Многократно проверено на практике :) Это и использование чужих механизмов (например, расширения MediaWiki, а форум мой до сих пор наполовину состоит из модифицированного punBB), и переписывание на данный фреймворк ряда коммерческих сторонних сайтов с готовыми и активно используемыми движками. Там происходила постепенная и незаметная подмена старого кода моим. Интеграция бывала совершенно незаметной со стороны готового продукта :)
>Ну не нравица вам реализация MVC у Zend, ну дополните ее или перепишите полностью.
Зачем, если у меня уровень абстракции выше (т.е. хочу с MVC пишу, хочу — без. Хочу, MVC на XSL сделаю, захочу — на шаблонах какого-нибудь iPB)?
И что касается велосипедостроительства… Тут ещё зачастую вопрос чей велосипед был раньше :D
Эти же механизмы у меня будут и на Java реализованы :) Хотя это несколько позже и без привязки к Web, в другом проекте. Основные принципы легко ложатся почти на любую платформу, лишь бы там были механизмы рефлексии.
>скоро разница исчезнет между серверной частью и клиентской.
Не уверен :) Точнее, даже «уверен, что не» :)
В системе всё есть. Постраничный список делается введением двух параметров в запрос массива объектов (номер страницы и число элементов на страницу) и вызовом одного метода из шаблона.
В коде:
$posts = objects_array('forum_post', array('order' => '-create_time', 'page' => $this->page(), 'per_page' => $this->items_per_page()));
В шаблоне:
{$this->pages_links()}
(опционально во втором случае могут быть аргументы, указывающие на стили и варианты отображения).
>Врятли XML можно назвать технологией и особенно механизмом, но мысль понял.
XML — это именно механизм хранения информации (данные или шаблоны) и технологии для работы с этим механизмом :)
В общем, как обещал, вечером покурю над XSLT (никогда не работал с ним) и для демонстрации расширения сделаю модуль XSLT-шаблонов тела страницы. Насколько я понимаю, основной затык у меня будет с конвертированием ассоциативного массива в DOM, понятный XSLT.
>Или это я Вас не так понял.
Видимо, мы где-то друг друга не поняли :) Ладно, если тема будет развиваться, то мы ещё обсудим недопонятое на более конкретных примерах :)
>Грубо говоря вызов метода из скрипта вида (или шаблона или лейаута).
Из Smarty-шаблона свободно вызываются любые методы объекта. Из PHP-шаблона — тем более :)
В общем, повторюсь, что шаблонный механизм — это именно сменный механизм. При желании и тот же Zend можно подключить, уровень абстракции у меня очень высокий :)
Что Вы предлагаете взамен? :)
>коро они загнутся. нужно не идти за модой а делать то что нужно.
Что нужно делать сегодня по-Вашему?
>по документации посоветовал бы побольше примеров. а именно Hello world. так легче остальным будет понять.
Будет целая серия. А так — неужели HelloWorld в виде вывода конкретного объекта по второй ссылке в первом сообщени — это черезчур сложно? :) Я просто не представляю, как можно хоть что-то конкретное сделать ещё проще :D
>а в документации на поверхности — побольше примеров от простых к сложным. и постарайтесь чтобы их исполнение — было действительно простым.)))
Постараюсь :)
Да. Но это пока ещё не пиар :)
>Неплохо было бы оширную статью написать, с диаграммами, с примерами.
Это пока именно попытка узнать, что людям нужно в документации в первую очередь. Документация для такого проекта не пишется на коленке за несколько вечеров, увы.
>P.S. Неплохо было бы еще и дизайнера нанять ;)
Да где ж взять дизайнера, готового работать просто так. А проект — некоммерческий, денег он не приносит и не будет приносить :)
>P.S.S. А система случайно не новый римейк «Атаки клонов»?
Не слышал про такую (ну, кроме одноимённого фильма :) )
Система имеет довольно глубокие корни, восходя ещё к офлайновой системе на Форте в конце 1990-х гг. Лет пять назад понемногу доросла до микроядерной системы на PHP. Одно из расширений микроядра, объектное, оказалось столь удобным, что понемногу весь остальной код был снесён, а объектное расширение перенесено на уровень ядра. В таком виде система стала уже фреймворком, где-то около пары лет развивается на весьма сложных задачах и, к моему удивлению, за этот срок ни разу не натыкался на идеологические ограничения скелета фреймворка. Т.е., похоже, базис у него заложен верный :D
А точнее?
>Такое уже на XML давно делают
В этом фреймворке нет жёсткой привязки к механизмам и технологиям. Если Вы имели в виду использование XML в роли шаблонов, то пишется соответствующий render-engine легко и быстро. Просто лично мне намного удобнее использовать Smarty. Но в заметках по ссылке особо отмечено, что движков отображения может быть сколько угодно и подменяться они могут даже в рамках одного объекта в зависимости от его внутренних условий :)
Пожалуй, вечером сяду и напишу Вам render_xml, просто как демонстрацию расширения функционала системы :)
>людям не удобно работать с вызовами функций, с вложенными массивами да и вообще с кодом
То есть букву «C» в MVC уже отменили? :) Или я Вас не понял? Как вы представляете работу системы без кода? :)
>И вообще, посоветовал бы Вам, выдрать этот помощник вида для вывода списка объектов
Честно говоря я не понимаю, о чём Вы ведёте речь :)
>и запихнуть его в что нибудь более распространенное, скажим в Zend Framework или Symfony
И Zend и Symfony не имеют нужной мне гибкости и расширяемости. А у последнего ещё и с MVC полный караул. По крайней мере уровня examples мне хватило :) Мешать шаблоны и PHP-код — не лучшая идея. Кстати, у меня тоже так можно. Но не нужно.
Вы, видимо, очень невнимательно читали пример.
Создание полностью развёрнутого MVC-модуля, это:
— 1 строка подключения модуля к ссылке
— 4 строки описания класса в две функции
— 2 строки в шаблоне
Это — много? Можно примеры, где то же самое будет писаться компактнее? :D
>а идеологическое развитие застряло где то в 2003-2004 годах
Поясните Вашу мысль. Что конкретно не нравится в идеологии моей системы? Или MVC, модульность и ORM сегодня уже идеологически не верны? :D Тогда, наверное, да, я где-то застрял. В общем, поясните.
>да и хорошая система на самом деле не должна быть огромная.
Система по сути микроядерная. И её ядро очень компактно. «Огромна» она — в плане количества модулей и расширений. Это, как бы, две большие разницы…
>а документация должна быть маленькая и понятная
Этот постинг и был написан с целью выяснения, на что при составлении документации обращать внимание. Очень, знаете ли, трудно писать документацию на то, чем пользуешься много лет. Если Вы невнимательно читали первый постинг, процитирую главное оттуда: «сразу трудно решить, какие направления в документации оформлять в первую очередь».
Я пришёл не столько рекламировать фреймворк, сколько просить помочь с мыслями по составлению документации. А в результате огрёб массу минусов, так что, не могу даже в свой блог написать более детальный и объясняющий постинг :)
Да, моё упущение. Фреймворк, как и большинство аналогичных решений на PHP, предназначен для разработки Web-сайтов под LAMP :)
(К сожалению, как я понял, из-за получения сразу нескольких минусов в комментариях, не могу в блог написать отдельный более детальный постинг.)
А так:
Характерные черты:
— Полный MVC
— Предельная модульность
— Высокая скорость обработки
— Простое использование статического кеширования
— Легко расширяемый ORM на разных носителях данных
— Очень лёгкая интеграция с любыми другими системами (ORM легко перенастраивается на сторонние источники данных)
В общем на те вещи, которые вручную писались сутками, на том же Symfony пишутся за часы, у меня нередко можно сделать за минуты. При этом результат высоко стабилен, хорошо защищённый от side-effects, легко рефакторится. Чтобы понять, что же делалось в том или ином модуле год спустя, требуются подчас считанные минуты. Это тоже большая редкость в сегодняшних системах :)
…
По упомянутому же «Секрету» (ага, у меня жена увлеклась этими новомодными веяниям) — увы, ничего хорошего сказать не могу. Модная во многие времена попытка объяснить чистую фантазию автора научными терминами, с которыми авторы знакомы понаслышке из бедного американского общего образования :)
У любого, знакомого с физикой хотя бы на уровне советского общего образования вызывает в лучшем случае улыбку, в худшем — огорчение от того, куда катится этот мир…
:)
По собственной практике — Perl в среднем быстрее, но не принципиально. Это языки одного уровня производительности.