CMF BORS©

    Начал, наконец, расписывать принципы работы своего фреймворка.

    Всех заинтересованных предлагаю комментировать. Система не просто большая, она огромная, и поэтому сразу трудно решить, какие направления в документации оформлять в первую очередь.

    Пример готового рабочего класса фреймворка

    Система мощная, простая, открытая (GPL), гибкая… Результат чего-то около 10 лет экспериментов и идеологического развития и около 5 лет написания.
    Поделиться публикацией

    Похожие публикации

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

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

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

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

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

        А так:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

            А точнее?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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