Как стать автором
Обновить

Комментарии 31

Вы думаете что все бросятся разбираться в вашем framwork?

Описали бы хотя бы что это и зачем.
>Описали бы хотя бы что это и зачем.

Да, моё упущение. Фреймворк, как и большинство аналогичных решений на PHP, предназначен для разработки Web-сайтов под LAMP :)

(К сожалению, как я понял, из-за получения сразу нескольких минусов в комментариях, не могу в блог написать отдельный более детальный постинг.)

А так:

Характерные черты:
— Полный MVC
— Предельная модульность
— Высокая скорость обработки
— Простое использование статического кеширования
— Легко расширяемый ORM на разных носителях данных
— Очень лёгкая интеграция с любыми другими системами (ORM легко перенастраивается на сторонние источники данных)

В общем на те вещи, которые вручную писались сутками, на том же Symfony пишутся за часы, у меня нередко можно сделать за минуты. При этом результат высоко стабилен, хорошо защищённый от side-effects, легко рефакторится. Чтобы понять, что же делалось в том или ином модуле год спустя, требуются подчас считанные минуты. Это тоже большая редкость в сегодняшних системах :)
10 лет прошли зря. Если вы ратуете за «мощная, простая, открытая (GPL), гибкая…» — флаг вам в руки.
вот только слово простая точно выкиньте из списка. разобраться то в ней не составляет труда, только слишком уж много
кода писать приходится (судя по тому описанию которое вы выложили)
а идеологическое развитие застряло где то в 2003-2004 годах. тогда это наверное было бы даже круто (и то только для масс)

да и хорошая система на самом деле не должна быть огромная. а документация должна быть маленькая и понятная (маленькая — всмысле структуры а не количества).

вывод — начал «за здравицу» — оказалось «за упокой»
>кода писать приходится (судя по тому описанию которое вы выложили)

Вы, видимо, очень невнимательно читали пример.

Создание полностью развёрнутого MVC-модуля, это:
— 1 строка подключения модуля к ссылке
— 4 строки описания класса в две функции
— 2 строки в шаблоне

Это — много? Можно примеры, где то же самое будет писаться компактнее? :D

>а идеологическое развитие застряло где то в 2003-2004 годах

Поясните Вашу мысль. Что конкретно не нравится в идеологии моей системы? Или MVC, модульность и ORM сегодня уже идеологически не верны? :D Тогда, наверное, да, я где-то застрял. В общем, поясните.

>да и хорошая система на самом деле не должна быть огромная.

Система по сути микроядерная. И её ядро очень компактно. «Огромна» она — в плане количества модулей и расширений. Это, как бы, две большие разницы…

>а документация должна быть маленькая и понятная

Этот постинг и был написан с целью выяснения, на что при составлении документации обращать внимание. Очень, знаете ли, трудно писать документацию на то, чем пользуешься много лет. Если Вы невнимательно читали первый постинг, процитирую главное оттуда: «сразу трудно решить, какие направления в документации оформлять в первую очередь».

Я пришёл не столько рекламировать фреймворк, сколько просить помочь с мыслями по составлению документации. А в результате огрёб массу минусов, так что, не могу даже в свой блог написать более детальный и объясняющий постинг :)
упс. промахнулся — ответил чуть ниже ;)

плюнул бы в карму плюсом — за старания — да у самого не хватило))
Эх, недоработали вы пока вывод списка своих объектов. Такое уже на XML давно делают, людям не удобно работать с вызовами функций, с вложенными массивами да и вообще с кодом. Не надо верстальщика заставлять писать на пыхапе. Я понимаю, что он не обламается, но все равно не надо.

5 лет — чего то это ну очень много, за такое время можно ОСь написать.

И вообще, посоветовал бы Вам, выдрать этот помощник вида для вывода списка объектов и запихнуть его в что нибудь более распространенное, скажим в Zend Framework или Symfony. Ну это чтобы работа стольких лет не прошла сря.
>Эх, недоработали вы пока вывод списка своих объектов.

А точнее?

>Такое уже на XML давно делают

В этом фреймворке нет жёсткой привязки к механизмам и технологиям. Если Вы имели в виду использование XML в роли шаблонов, то пишется соответствующий render-engine легко и быстро. Просто лично мне намного удобнее использовать Smarty. Но в заметках по ссылке особо отмечено, что движков отображения может быть сколько угодно и подменяться они могут даже в рамках одного объекта в зависимости от его внутренних условий :)

Пожалуй, вечером сяду и напишу Вам render_xml, просто как демонстрацию расширения функционала системы :)

>людям не удобно работать с вызовами функций, с вложенными массивами да и вообще с кодом

То есть букву «C» в MVC уже отменили? :) Или я Вас не понял? Как вы представляете работу системы без кода? :)

>И вообще, посоветовал бы Вам, выдрать этот помощник вида для вывода списка объектов

Честно говоря я не понимаю, о чём Вы ведёте речь :)

>и запихнуть его в что нибудь более распространенное, скажим в Zend Framework или Symfony

И Zend и Symfony не имеют нужной мне гибкости и расширяемости. А у последнего ещё и с MVC полный караул. По крайней мере уровня examples мне хватило :) Мешать шаблоны и PHP-код — не лучшая идея. Кстати, у меня тоже так можно. Но не нужно.
>Или MVC, модульность и ORM сегодня уже идеологически не верны?

именно. придуманные десяток лет назад стандарты и направления — уже давно не отвечают текущим требованиям по скорости разработке, удобству поддержки и самое главное скорости изменения.

да и MVC. это конечно хорошо — но не то, и то что сейчас модно делать движки MVC — временно. скоро они загнутся. нужно не идти за модой а делать то что нужно.
в этом проблема почти всех программистов. делают продукт по своим интересам — и думают что помогают миру — хотя даже не удосужились что нужно этому самому миру. альтруизм попахивающий эгоизмом))

по документации посоветовал бы побольше примеров. а именно Hello world. так легче остальным будет понять.
самый первый вопрос возникающий — как мне сделать чтобы выводилась страничка HEllo world! — а потом потихоньку углубляйтесь.
если такая страничка будет действительно простой — люди потянутся. но если чтобы написать такую страничку нужно
прочитать минимум А4 — смысл в таком движке??

поэтому премудрости оставьте в глубине и для тех кому они действительно нужны. а в документации на поверхности — побольше примеров от простых к сложным. и постарайтесь чтобы их исполнение — было действительно простым.)))

иначе какой смысл во всём это? ))
>именно. придуманные десяток лет назад стандарты и направления — уже давно не отвечают текущим требованиям по скорости разработке, удобству поддержки и самое главное скорости изменения.

Что Вы предлагаете взамен? :)

>коро они загнутся. нужно не идти за модой а делать то что нужно.

Что нужно делать сегодня по-Вашему?

>по документации посоветовал бы побольше примеров. а именно Hello world. так легче остальным будет понять.

Будет целая серия. А так — неужели HelloWorld в виде вывода конкретного объекта по второй ссылке в первом сообщени — это черезчур сложно? :) Я просто не представляю, как можно хоть что-то конкретное сделать ещё проще :D

>а в документации на поверхности — побольше примеров от простых к сложным. и постарайтесь чтобы их исполнение — было действительно простым.)))

Постараюсь :)
>неужели HelloWorld в виде вывода конкретного объекта по второй ссылке в первом сообщени — это черезчур сложно?

helloworld — он и должен быть helloworld)) откуда мне знать (допустим я мало что смыслю) что там за такие объекты и откуда они вобще тут взялись? ))

>Что Вы предлагаете взамен? :)

хм. скоро действительно предложу, но сейчас рановато.

>Что нужно делать сегодня по-Вашему?

не зацикливаться на одном языке. смотреть изучать различные механизмы в том числе и клиентское программирование — если хорошо подумать натолкнет на дельные мысли. скоро разница исчезнет между серверной частью и клиентской.
>не зацикливаться на одном языке

Эти же механизмы у меня будут и на Java реализованы :) Хотя это несколько позже и без привязки к Web, в другом проекте. Основные принципы легко ложатся почти на любую платформу, лишь бы там были механизмы рефлексии.

>скоро разница исчезнет между серверной частью и клиентской.

Не уверен :) Точнее, даже «уверен, что не» :)
> А точнее?

Ну например постраничный список и д.р.

> В этом фреймворке нет жёсткой привязки к механизмам и технологиям.

Врятли XML можно назвать технологией и особенно механизмом, но мысль понял. Надеюсь вы все таки реализуете такую поддержку.

> То есть букву «C» в MVC уже отменили? :)

Контроллер, немного другая вещь :) Здесь мы говорим скорее о Виде. А работу системы без кода я вообще не представляю. >_< Или это я Вас не так понял.

> Честно говоря я не понимаю, о чём Вы ведёте речь :)

Ну это понятие из Zend`а. Грубо говоря вызов метода из скрипта вида (или шаблона или лейаута).

С помощью них я реализую вашу консрукцию вида

… извеняюсь, копипаст не прошел

$posts = objects_first('forum_user', array('order' => 'reputation'));

> И Zend и Symfony не имеют нужной мне гибкости и расширяемости.

Ну не знаю как с Symfony, но в Zend, замечательная реализация MVC. Во всяком случае все задачи, которые передо мной стояли в контесте MVC я прекрастно на нем реализовывал. И вообще, это утверждение заслуживает разъяснения.

> Мешать шаблоны и PHP-код — не лучшая идея. Кстати, у меня тоже так можно. Но не нужно.

Это можно везде, на то это и пыхапе.

А вообще, реализацию CMF без использования других фреймворком или их отдельных компонентов, ну например того же Zend, я считаю велосипедоводством. Ну не нравица вам реализация MVC у Zend, ну дополните ее или перепишите полностью. Тоже самое касается Symfony и д.р.
>А вообще, реализацию CMF без использования других фреймворком или их отдельных компонентов, ну например того же Zend, я считаю велосипедоводством.

Уже писал, что мой фреймворк очень легко цепляется к чужим системам. Многократно проверено на практике :) Это и использование чужих механизмов (например, расширения MediaWiki, а форум мой до сих пор наполовину состоит из модифицированного punBB), и переписывание на данный фреймворк ряда коммерческих сторонних сайтов с готовыми и активно используемыми движками. Там происходила постепенная и незаметная подмена старого кода моим. Интеграция бывала совершенно незаметной со стороны готового продукта :)

>Ну не нравица вам реализация MVC у Zend, ну дополните ее или перепишите полностью.

Зачем, если у меня уровень абстракции выше (т.е. хочу с MVC пишу, хочу — без. Хочу, MVC на XSL сделаю, захочу — на шаблонах какого-нибудь iPB)?

И что касается велосипедостроительства… Тут ещё зачастую вопрос чей велосипед был раньше :D
Ну если действительно так, что уровень абстракции у вас выше, то это просто прекрастно.

Что могу сказать, пишите документацияю.

Кстати, по какой лицензии собираетесь распространять? Если как открытое ПО, то могу предложить интеграцию вашего фреймворка и моего на основе Zend`a, PhpDoctrine и Php-ext.
>Кстати, по какой лицензии собираетесь распространять?

Планирую по GPL, только не задумывался ещё, v2 или v3.
Отлично, буду ждать релиза.
>Ну например постраничный список и д.р.

В системе всё есть. Постраничный список делается введением двух параметров в запрос массива объектов (номер страницы и число элементов на страницу) и вызовом одного метода из шаблона.

В коде:
$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 можно подключить, уровень абстракции у меня очень высокий :)
Простите, а что там насчёт «гибкости и расширяемости» в Zend и Symfony (конкретно в ZF). Если Вам что-то не удалось сделать, ещё не значит, что фреймворк не гибкий.
Приведите пример.
Я не говорю, что в ZF чего-то сделать нельзя. Просто он громоздкий и неудобный. На те же действия требует в разЫ больше писанины.

Кроме того, повторю, что у меня просто выше уровень абстракции. Вещи, которыми занимается Zend (о Simfony речи вообще не идёт) реализуются у меня относительно небольшими дописываемыми модулями. При желании можно хоть эмулятор Zend-фреймворка на моём написать :) И принимать/понимать его расширения.

Но, боюсь, на словах этого не обяснить, и Вам придётся (если, конечно, Вами движет реальный интерес к сравнению, а не нонконформизм или простое желание задавить новичка в вашей тусовке), ждать, пока я оформлю комплект простых примеров.
Давить не собирался, но комплект примеров будет интересен.
Попробовал сейчас написать шаблонизатор для XSLT.

В принципе, ничего сложного, всё в единицы строк укладывается, но есть одна принципиальная проблема.

Если я правильно понял, то XSLT-процессор принимает данные только в виде DOM. И передать PHP-объект туда нельзя в принципе.

Значит, все нужные в шаблоне данные нужно извлекать из объектов дополнительным действием.

Т.е. получаем, скажем, массив объектов, а потом трансформируем его в DOM-объект, указывая нужные аргументы в коде.

Некрасиво + правки во View тянут за собой правки в Code.

Есть мысли, как этого избежать?
Что-то Вы не так поняли. XSLT-процессор форматирует XML дерево, при том на стороне клиента. Само-собой ни о каком PHP речи быть не может. В данном случае задача PHP лишь построить правильно XML дерево. А правки во View по определению не могут «тянут за собой правки в Code» (в данном случае Вы имеете ввиду Controller я так понимаю). Возможно, Вам будет привычнее формировать готовый HTML на стороне сервера (на это есть DOMDocument и XSLTProcessor (libxslt2))
Неужели Вы никогда не слышали о серверном 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)),
);

дописываем ещё

'xml_fields' => array('users' => 'title reputation'),

И формирователь дерева создаст дерево только с нужными параметрами.



Затык пока случился только на формировании DOM-дерева из ассоциативного массива. В частности — на вложенных простых массивах.

Так что за вечер задачу решить не удалось, но не из-за ограничений фреймворка :)
>Я думал, что Вас интересует банальная XSLT-шаблонизация, разбираемая сервером — это очень распространённая тема в PHP-сообществе.

Ну что вы, для меня это было давно. Вообще-то ветку инициировал не я…

>Всё хорошо, но завтра дизайнеру понадобится вывести другое поле.

Однако, над интересными проектами Вы работаете. Судя по всему дизайнеры у вас в штате. Есть гигантский объект, который заранее перекрывает все маслимые и немыслимые потребности дизайнера и который в определённом контексте используется на 10%, тем не менее он всё равно создаётся полностью. При этом дизайнер решает, будет ли добавлено новое поле.

Идея XSLT-шаблона заключается в том, что один шаблон одинаково хорошо обрабатывает различные вариации дерева. Поэтому об XSLT вёрстве и говорят, что нужно повернуть сознание.
Поэтому в Вашем случае, не дизайнер должен решить (он уже свою работу сделал и уволен), а разработчик. Если он решит, что нужно новое поле формы (например появилось поле в базе данных), то шаблон сам отобразит его после добавления нового элемента дерева.
У нас с Вами очень разные проекты, в которых мы участвуем :)
Для PR проекта надо грамотный подход еще.
Какая бы система хорошей не была, без PR — она ничто, останется забытой.
Неплохо было бы оширную статью написать, с диаграммами, с примерами.

P.S. Неплохо было бы еще и дизайнера нанять ;)
P.S.S. А система случайно не новый римейк «Атаки клонов»?
>Для PR проекта надо грамотный подход еще.

Да. Но это пока ещё не пиар :)

>Неплохо было бы оширную статью написать, с диаграммами, с примерами.

Это пока именно попытка узнать, что людям нужно в документации в первую очередь. Документация для такого проекта не пишется на коленке за несколько вечеров, увы.

>P.S. Неплохо было бы еще и дизайнера нанять ;)

Да где ж взять дизайнера, готового работать просто так. А проект — некоммерческий, денег он не приносит и не будет приносить :)

>P.S.S. А система случайно не новый римейк «Атаки клонов»?

Не слышал про такую (ну, кроме одноимённого фильма :) )

Система имеет довольно глубокие корни, восходя ещё к офлайновой системе на Форте в конце 1990-х гг. Лет пять назад понемногу доросла до микроядерной системы на PHP. Одно из расширений микроядра, объектное, оказалось столь удобным, что понемногу весь остальной код был снесён, а объектное расширение перенесено на уровень ядра. В таком виде система стала уже фреймворком, где-то около пары лет развивается на весьма сложных задачах и, к моему удивлению, за этот срок ни разу не натыкался на идеологические ограничения скелета фреймворка. Т.е., похоже, базис у него заложен верный :D
ой, выкиньте копирайт из заголовка, умоляю
Это «игра букв» с названием. Bors© == Borsc == борщ :)
Код напомнил Drupal. Хорошо это или нет — решать не мне…
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории