Добрый вечер, друзья! Решил обсудить одну интересную, на мой взгляд, тему: концепции и парадигмы разработки систем. Причем речь идет в данном случае о любого рода системах, будь то CMS, CMF, FW, CRM, ERP, ORM, QBuilder'ы, адаптеры, шаблонизаторы, раутеры и многие другие разработки в сфере веб-программирования на PHP (строго говоря все это относится к программированию в целом, но на проекте php.ru, думаю, имеет смысл обсуждать именно в контексте разработок на языке PHP). С момента начала моего знакомства с PHP, когда я только пытался разобраться с областью его применения и пытался написать какие-то простейшие 'Hello World' скрипты и до момента разработки коммерческих проектов, которые постепенно стали основным видом деятельности, я прошел некоторый, так сказать, путь становления, который, как мне кажется, знаком многим разработчикам. Сейчас мне кажется, что этот путь заключался в преобразовании принципов моей логики, в бесконечной череде изменения принципов мышления, и в некоторой степени в эволюции сознания, так как для меня совершенно очевидно, что когда-то раньше я думал совершенно не так как сейчас - раньше я не замечал самых важных деталей. Все это лирическое отсутпление, на мой взгляд, достаточно значимо, так как я предполагаю, что этот путь знаком многим. Раньше я смотрел на сложные системы как на нечто огромное и невообразимо сложное, на нечто, что в принципе невозможно сделать одному. Со временем передо мной возникали разные задачи, я много экспериментировал: реализовать какие-то функции на сайте заказчика, реализовать какие-то свои идеи, обработчики, парсеры, системы управления данными, упростить и сгруппировать код и т.д... Постоянная работа над кодом, бесконечный рефакторинг заставляют пересматривать то, что делал уже сотни раз, заставляют взглянуть иначе на какие-то, казалось, обычные решения по-другому. Постепенно простые схемы поведения "скрипт->страница" превращались в сложные виды взаимодействия кода, которые выделялись в модули, инкапсулируя логику, основные наборы функций - в библиотеки, код эволюционировал вместе с моей логикой. Где-то я слышал фразу, что "код - отражение принципов мышления программиста, его создавшего", - и, очевидно, это так. Шаг за шагом конкретное понятие "сайт" становилось все более абстрактным: как таковой набор информации в виде результирующих страниц постепенно стал превращаться из конкретизированного результата работы строго определенных модулей в некую условную реакцию разрозненной системы. Простые модульные структуры, которые обеспечивали лишь удобство программирования, инкапсулируя логику в отдельные сущности, начали превращаться в нечто другое, они начали восприниматься мной как независимые самостоятельные объекты со своей внутренней структурой произвольного уровня сложности, (словно клетки большого многоклеточного организма), существующие в рамках времени исполнения и в этих коротких исмпульсах в процессах взаимодействия между собой, они рождают какие-то программируемые результаты. Давно хотел поделиться, что программирование похоже на чтение какого-нибудь интересного литературного произведения, которое сначала кажется полной ерундой, но страница за страницей ты начинаешь втягиваться в сюжет, и он всецело поглощает сознание и в большей степени все свободное время. Так, мне постепенно становились интересными вопросы не конкретных реализаций или конкретных систем, а принципы, парадигмы, на которых они основаны. Я стал понимать, что важейшим звеном, которое я не замечал ранее, является идея, положенная в основу принципов создания, а не сами функциональные наборы логики и результаты, что бы они ни делали, будь то простые пейджеры или сложные для восприятия парсеры и каталогизаторы поисковых модулей. И вот об этом я хотел бы поговорить. Эта тема не относится к конкретным алгоритмам, здесь нет особого смысла говорить, как именно функционирует тот или иной объект, так как каждый волен реализовать концепции по-своему. Но мне хотелось бы услышать мнение участников о том, какими они видят те системы (и подсистемы), которые хотели бы создать (применительно к сайтостроению), на основе каких парадигм, какие принципы положены в основу, даже если это идеи граничащие с бредом с точки зрения большинства. Скажу честно, я уважаю людей, которые стремятся к тому, чтобы в свободное время, вместо высижывания задницы на диване с пивом, стараются развиваться, находят время для творчества и экспериментов вопреки всему. Я предлагаю обсудить вопросы конструирования систем, их состав, взаимодействия и уровни. Я предлагаю свободно обмениваться идеями и применять их в своих работах, модифицировать и развивать существующие парадигмы, предлагая самые различные варианты решения. Я прекрасно понимаю, что свободная форма выражения идей повлечет за собой просто хаотичный поток информации, поэтому я бы хотел сразу призвать к конструктивному общению, я ЗА то, чтобы вы писали большие развернутые ответы, я считаю важным видеть ход рассуждения по мере прочтения текста, чтобы идея передавалась не от сообщения к сообщению, а была хотя бы в общих чертах как можно более полно передана одним главным постом в форум. Я убежден, что наше воображение оперирует образами, поэтому я уверен, что и передавать свои идеи необходимо так же - образами, где холстом является - монитор, а набором кистей - текст и коды. Поэтому "рисуйте" то, что вы считаете важным, даже если вы не так часто выражаете свои идеи - здесь нет хорошо или плохо, любое "а что если" является великолепным результатом.
Набросок первый Просто не передать словами, насколько точно вышесказанное совпадает с моими разрозненными размышлениями на эту тему. Вероятно, это и есть искомый импульс, который способен побудить к процессам созидания. На некотором этапе понимания движок сам начинает едва уловимо диктовать логичные принципы для дальнейшего своего развития. Однако это лишь результат многократного моделирования в сознании различных процессов и причинно-следственных связей. Таким образом, в процессе перевода на PHP5 MVC-прототипа на PHP4 от неизвестного автора (спасибо ему за интересный код), со значительными модификациями да интеграцией собственных наработок возникла идея «полномодульного» движка, в котором контроллер разбит на управляющие блоки, унаследованные от абстрактного класса Module. По сути, каждый модуль ядра - это подборка действий, направленных на обслуживание некой сущности. Так сказать, удачный способ группировки, которому и отводится основное внимание нынешнего поста. Что точка входа Engine, что FrontEnd, BackEnd, любой отдельно взятый конечный модуль - всё объединено единым программным интерфейсом описания модуля (методы Module::getSummary, Module::getBackActions, FrontModule::getFrontActions и т.п.), может быть подключено к контрольной панели и настроено. В модуле можно выделить заголовочную часть (например, класс модуля Forum), которая содержит метод описания действий, и контейнер методов (обычно унаследованный от заголовочной части, например Forum_Thread extends Forum - заменяем _ на /, добавляем в конец '.php' и получаем место хранения в папке modules - по стандарту). Любое действие выполняется для некоторого пути. Каким образом? Путь ломается на две части: ту, для которой удалось установить страницу в базе (на таблице id_page-id_parent) и ту, которая будет передана модулям, связанным с этой страницей. Ранее я уже упоминал об этих принципах: ссылка. Такой вот первый набросок, который частично является переложением/развитием принципа управляющих цепей ядра из однажды опубликованной мною статьи в научном журнале по дипломному проекту, где модуль-потомок является расширением функционала модуля-родителя и задействует средства идентификации, которым обладает родитель (по ключу потомка можно выстроить всю цепь до корня ядра). Эта штука позволила строить сайт в сайте и моделировать структуру ВУЗа с сегментированием прав доступа (локальные администраторы и пользователи подразделения), но на ранних этапах обладала некоторыми недостатками в SEO и была лишена той гибкости разработки, которую предоставило ей слияние с новым производственным проектом.
Поделюсь и своими эксериментальными разработками, немного позже обсудим некоторые моменты, это будет очень полезным обменом опыта: Где-то с момента осознания разделения кода по функциональному назначению я стал применять в разработках различных проектов MVC парадигму. Так, в частности, я использовал Smarty-like компилируемые шаблоны, а также наборы моделей завязанные на контроллеры для обработки тех или иных действий (добавление и сбор сведений из БД: обработка массивов данных, фильтры и т.д.). В целом model-view-controller парадигма позволила мне совершить, скажем так, маленькую революцию в плане стандартизации и скорости разработки, ведь от времени сборки конечной полнофункциональной системы напрямую зависела и оплата моей работы заказчиками. С точки зрения бизнеса этот принцип разработки и сейчас является, пожалуй, мировым стандартом. Может быть, с моей стороны будет звучать несколько грубо, но на базе FrameWork'ов использующих MVC-парадигму разработки можно в буквальном смысле "лепить и печь" сайты как пирожки. Все было бы замечательно, если бы не одно но... Я никак не мог избавиться от мысли, что конструкция MVC не дает мне развернуться, что мне не хватает пространства для действий в рамках трех функциональных сущностей: модели, вида и контроллера. Я перенасыщал кодом контроллеры, а затем выделял избытки в хелперы, когда мне требовалась прослойка бизнес логики, не относящаяся к модели, а являющаяся поведенческим фактором. И если MVC полностью устраивала меня с точки зрения бизнеса, то она вызывала некоторый диссонанс в моей логике, я постоянно ощущал присутствие какого-то легкого дискомфорта. Может быть я слишком странно отношусь к своей работе, но я не мог не обратить внимание на то, что мне был необходим иной инструмент, иная парадигма, которая позволила бы мне, скажем так, вздохнуть полной грудью. Я много читал статьей и различных мнений по поводу "велосипедостроения", я прекрасно понимал всю критику со стороны разработчиков, оценивающих поделки своих же коллег, но я все же был категорически против того, чтобы на корню обрубать потенциал многих людей, способных из маленького неуклюжего зерна взрастить мощную и стройную систему, основанную на иных принципах и стандартах. Я осознавал, а сейчас осознаю еще более остро тот факт, что разработка идеи, парадигмы и как следствие систем на ее основе, являющихся сегодня де-факто в веб-разработке, которые полировались годами десятками граздо более высококвалифицированных сециалистов, чем я (я все же считаю, что только начал путь веб-разработки и программирования), кажутся непоколебимыми, они просто не поддаются критике, являясь шаблоном, используемым для достижения цели. Но стулья тоже по своей сути одинаковы, и тем не менее, один и тот же стул может показаться кому-то удобным, а кому-то нет, несмотря на то, что его функциональное предназначение строго определено и абсолютно применимо на практике. Более того, меня за все время подобных размышлений не покидала мысль о том, что "вся структурная мощь огромного раскидистого дуба заложена в одном маленьком желуде". Постепенно я приходил к тому, что мне неудобны, используемые мною FW, я все больше становился из обычного разработчика эдаким предвзятым критиком со своими "замашками". Мне не нравилось и до сих пор не нравится то, что считается стандартом. И я решил, что не имеет смысл внедрять что-то в уже устоявшиеся механизмы. Если для вас очевидно, что можно нечто сделать удобнее для себя, то нет никакого смысла пытаться объяснить и оправдать собственное стремление к ощущению комфорта, в конечном счете любое ощущение сугубо индивидуально. Так я логически определил для себя тот факт, что мне не просто можно, но и нужно пытаться улучшать собственные разработки, вопреки любым мнениям. Поэтому я стал эксериментировать на своих проектах. Я не пытался реализовать конкретное действие, я начал с того, что не относится к программированию напрямую: я взял пустую тетрадь в клетку и обычную шариковую ручку и начал записывать тезисно все то, что я считаю лучшим из собственного опыта разработки. Я много моделировал, но заметил за собой привычку все записывать, даже какие-то мысли, идеи (я так и писал: идея - создать такой-то блок, такое-то межмодульное взаимодействие и т.д.), и спустя какое-то время начал понимать, что мои записи - ход эволюции идеи, которую можно наглядно пролистать, можно посмотреть как она изменялась в течение времени, как от очередной попытки сделать модульную систему, я пришел к какой-то более сложной и гибкой, но в то же время удобной исключительно для себя парадигме. Я хотел сделать быструю систему, мне действительно казалось и кажется неудобным использование излишних слоев абстракции как в целом, так и над базами данных, я все дальше и дальше уходил от концепции ORM, как бы возвращаясь обратно во времена, когда я только пытался написать первые адаптеры для БД. Аналогичным образом ход моих мыслей привел меня и к тому, что слой абстракции компилируемых шаблонов - крайне избыточен в веб-проектах в целом. Эта интересная находка, которая позволила разработчикам на ходу смешивать шаблоны и коды в исполняемые блоки породила в своем развитии сложнейший слой абстракции над собственным синтаксисом с собтвенным транслятором инструкций. Я много думал над тем, что вынесение логики и представления в разные сущности является отличным решением разделения функционального обеспечения проекта, но в то же время развитие представления в компилируемый шаблон породила обратный эффект встраивания более высокоуровневой (с точки зрения слоев абстракции) логики в представление, что в свою очередь очень серьезно повлияло на подсистему шаблонизации. Иногда мне казалось, что шаблонизация сложных составных структур с обесечением некоторой минимальной динамики (реакция на контекст, окружение, внешние переменные) доходит до абсурда, выраженного в форме сквозной логики между всеми слоями абстракции от чистого PHP до вымышленного языка конструкций интерпретатора компилируемых шаблонов. Не стоит при этом забывать и про то, что сама инициализация любой реакции при этом строго завязана на совокупности контроллеров (и привлечении т.н. хелперов, если логика контроллера нуждается в обесечении "поведения"), которые в свою очередь так или иначе могуть быть завязаны на моделях. В целом, в сложных ситуациях я сталкивался со "сагетти-кодом", хотя изначально паттерн предполагает безотказный как автомат Калашникова и простой принцип: { точка входа } -> { маршрутизация } -> { MVC }. После многих дней и бессонных ночей размышлений, я понял, что мне нехватало поведения объектов, реакций и иного представления самого процесса сборки информации. Я начал осознавать, что мне более привычна модель, которая крайне напоминала бы субъектно или агентно-ориентированное программирование, но не в контексте перманентных процессов (служб или демонов), а в контексте кванта времени выполнения кодов виртуальной средой исполнения PHP-кода. Я начал ясно понимать, что я где-то на уровне подсознания заведомо начинаю писать логику системы и относится к ней как к чему-то обладающему программируемому мной зачатку сознания и набора инстинктов. Я где-то в глубине души уверен, что создаю "живые" системы и этот стиль мешал и мешает мне адекватно воспринимать строгие парадигмы. Я просто не понимал раньше, что не хотел "чертить строгие линии на миллиметровке", а хотел все это время "рисовать яркими красками на холсте", и что это проявление природы моего сознания, что каждый банальный проект, который по сути всего-навсего очередной сайт, CRM или ERP, в моем комфортном представлении структурно должен так же восхищать, как квантовая природа материи, а не грубый шестярной механизм с паровым двигателем, даже если и то и другое на выходе даст один и тот же результат. Я знаю, что сделать что-то стоящее крайне сложно. Я не смогу один воздвигнуть пирамиду или построить небоскреб, но сделать вполне комфортное кресло, в рамках приведенной мной метафоры в самом начале текста, я думаю, что вполне способен, даже если на это будут уходить часы свободного времени по вечерам или ночам в течение долгих месяцев. Весь этот труд не вустую - это развитие собственного мышления, это бесценный опыт. Что для нас есть страница того или иного веб-сайта? Просто набор структурированных данных, словно слоеный пирог из многочисленных технологий, которые формируют визуальный образ на экране: обработка запроса, формирование каркаса страницы и выдача ее браузеру для дальнейшего этапа рендеринга, стилизации и визуализации данных. Очевидно, что инициатором всех действий явно или косвенно является сам пользователь. Именно человек, от начала включения компьютера и до завершения работы так или иначе влияет на процессы, происходящие в системе. Даже простое включение ПК - это уже своего рода инициализация раскрутки операционной системы. Если же экстраполировать этот ход рассуждений на все то, что делает пользователь, когда смотрит какой-то веб-ресурс, то можно сказать с достаточной долей уверенности, что именно его действия - это та самая внешняя среда или раздражитель для перцепционного механизма системы, формирующей абстракцию, воспринимаемую пользователем как веб-сайт. Сайта нет. Это лишь иллюзия восприятия. Череда реакций различных компонент, формирующих различные части того единого целого образа, который мы считаем страничкой. И так страничка за страничкой мы формируем представление о некой информационной структуре, за которой закрепляем в нашем сознании адрес, называя это "сайтом". Мне кажется это очень важной деталью, и, по крайней мере для себя, я четко выделяю ее, как одну из первопричин, как вектор развития системы, как ген формирующий какие-то опредленные свойства конечного организма. Совершенно логично, что с точки зрения компонент системы можно выделить две основные, скажем так, стороны, которые взаимодействуют между собой: FrontEnd и BackEnd, в контексте взаимодействия пользовательского браузера и веб-сервера, где FrontEnd представлен JS-функционалом и является по сути рецеторными клетками в рамках приведенной аналогии, в то время как BackEnd - часть центральной нервной системы, отвечающая за реакции, за обратные импульсы, за инициализацию действий со стороны системы. Повсеместное применение AJAX действительно преобразило многие веб-ресурсы, и это не просто веяние моды - это эволюция, происходящая на наших глазах в наше время. AJAX стал неким подобием нейроинтерфейса, он словно нервные волокна соединяет мозг с удаленными в браузеры пользователей рецепторными блоками. И такое положение вещей не кажется чем-то новым, оно не является в принципе радикальным нововведением, но в целом этот маленький шажок в сторону юзабилити несет в себе колосальные архитектурные возможности с точки зрения разработки. Но мне следует повториться: так что же такое обычная страница веб-ресурса в контексте взаимодейстующих сторон системы? Очевидно, что страница не является BackEnd'ом, но и в то же время сама сущность страницы, воспринимаемая нами, не является FrontEnd частью как таковой, хотя мы и привыкли понимать тот факт, что весь JS функционал является частью документа, или как минимум обязан быть инициализирован в нем. Я постепенно пришел к представлению о том, что сама суть страницы с точки зрения представления является совершенно отдельной сущностью - "MiddleEnd", как бы странно или непонятно это ни звучало. Иначе говоря, страница является композиционной сценой, совершенно отдельно от наличия в ней FrontEnd-сущности, так как последняя вполне поддается любой динамике, о чем я упомяну позже. Если немного обобщить все выше сказанное, то пользователь, совершающий те или иные действия в рамках страницы веб-ресурса заставляет перцепционный механизм возбуждать сигналы через AJAX-интерфейс, которые формируют реакции, основанные на поведенческих факторах системных компонент, и в некотором роде заставляет сразу обе сущности (BackEnd и FrontEnd) реагировать, и как следствие видоизменять совершенно отдельную сущность сцены MiddleEnd, изменять предствление, причем, более того, корректируя не только саму сцену, но и сам компонент FrontEnd. Иными словами, пользователь вполне способен спровоцировать такую реакцию системы, которая произведет не только модификацию композиции (MiddleEnd), но и приведет к изменению FrontEnd сущности, динамически изменяя рецепторы и поведенческие факторы, добавляя или уничтожая нервные окончания и как следствие механизмы реакций системы. На мой взгляд, такой подход к рендерингу композиции страницы (compositing) - одно из проявлений метапрограммирования в области веб-разработок. Что такое шаблонизация? По большому счету - это смешение (Bind) разметки с данными и не более того. Любой обвес этого процесса слоями абстракции, обладающими своей собственной логикой приводит к усложнению и увеличению реакции системы на раздражители, так как слой абстракции мешает реализовать саму суть процесса, накладывая целый пласт избыточной логики, даже если это было сделано с точки зрения удобства и ускорения программирования, а по сути для унификации - что и является первопричиной избыточности. Но я убежден, что всегда получать задуманный фото-шедевр, нажав на одну единственную кнопку спуска в автоматических настройках, просто невозможно. Шаблонизация сама по себе должна представлять собой тончайший слой в системе. По своей идеологии PHP и был создан, как язык для удобной и быстрой шаблонизации. Я считаю нужно отдать ему должное и использовать по назначению его возможности. Но как можно было подумать шаблонизация не является процессом логики формирования композиции (MiddleEnd), шаблонизация лишь слой, лишь средство формирования части кода в буфере вывода, шаблонизатор не умеет, не знает, и не должен осознавать принципиальную форму конечной композиции. Шаблонизатор не имеет никакого отношения к тому, что я определил как некую промежуточную сущность - сцену (композицию). Композиция абстрактна, ее проявление для пользователя - лишь трансформируемая системными компонентами иллюзия. Для композиции необходима отдельная сущность, обладающая "сознанием", умеющая реагировать, понимающая, что такое композиция в декларативной форме. Такая сущность выделяется в отдельный структурный компонент композитинга сцены, или проще говоря - композитор (compositor). Используя стандартную схему bootstrap'а системы, через точку сборки и инициализацию ядра логики сборки системы, мы маршрутизируем все запросы в Router, который по сути является не инструментом проброса на контроллер, а самостоятельной сущностью, он обладает возможностью взаимодействовать с любыми другими сущностями, будь то сущности композитинга, шаблонизации, других маршрутизаторов и ядер логики функциональных модулей. Почему-то я представляю себе аналогию подобного поведения взаимодействием кварков в элементарных частицах. Со временем я понял, что опыт разработки на MVC и мои стремления к комфорту, к новым возможностям привели меня к разработке несколько иной концепции, иной парадигмы, которая дает немного больше свободы воображению и гибкости в реализации, по крайней мере исключительно для меня. Каждое обращение к системе, каждая ее реакция - это минимизированная цепь событий, начинающаяся с точки сборки, нет никаких библиотек, никаких уровней абстракций, нет никаких каскадов обращений к БД, нет никаких "спагетти", есть только программирование поведений, условных реакций и механизмов, есть только концентрация над созданием "разума" системы. Не судите строго, я не хотел и не хочу углубляться в скучные дебри собственных реализаций. Как я уже сказал - каждый способен по-своему воплотить ту или иную концепцию в коде. Я очень много времени потратил на то, чтобы сформировать правильное понимание необходимого инструмента, не с точки зрения реализации, а с концептуальной точки зрения, с точки зрения парадигмы, которую сейчас в бесконечных экспериментах пытаюсь реализовать, применительно к бизнес-процессам. Я рад, если быть может слегка сумбурным изложением, подтолкну многих разработчиков, знакомых с подобными ситуациями, к размышлению и развитию собственных великолепных идей. Я надеюсь, что в наше время есть многие, кто способен не просто выполнять рутину, а искать и исследовать новые горизонты. Я рад если меня поймут те, кто обожает "рисовать картины программными кодами".
Если условно разделить развитие моей системы на поколения (первое - цепь управления, второе - MVC, третье - синтез двух первых, ещё в работе), то в первом из них было нечто, напоминающее описанное Вами поведение: есть базовый класс Chain, от него по нисходящей древовидной иерархии строится цепь сущностей (например, ветка Chain -> User -> Policy -> Department -> ... -> Page -> Paragraph -> Attachment). Каждое звено обладает средствами собственной идентификации/инициализации, каждый потомок (в той или иной мере) обладает сведениями о ключе родителя и способен при необходимости отдать команду на инициализацию родителей. В системе поколения I нет единой точки входа и это её недостаток/преимущество: недостаток в плане централизации, но преимущество в плане очевидности - любой скрипт является прямой реализацией конечной логики и для удобства создаётся как "директория/index.php", например "/page/add/index.php". В первых строках производится инициализация цепи с уровня той сущности, которая способна предоставить разработчику необходимые и достаточные для сценария сведения. В этот момент система проходит по звеньям вышестоящих уровней и способна предоставить информацию о родительских сущностях (если не удалось получить GET-идентификатор текущего узла, управление передаётся родительскому - звенья цепи способны выпадать и возвращать null, если в них нет необходимости). Код (Text): <?php // В этом сценарии работаем с сущностью параграфа. $chain = Chain_Paragraph::getInstance(); $db = $chain->db; // // К этому моменту уже проведена инициализация цепи, аутентификация и авторизация. // $user = $chain->getNodeData('user'); # обращение к сведениям вышестоящего узла $entity = $chain->getNodeData('paragraph'); // ... некоторый код, в зависимости от задач. Для разработки необходимо понимать разве что связи между сущностями (можно держать на диаграммке), которыми оперирует система (объекты реального мира или некие связующие их абстракции). Генерация html взята от прототипа Softtime. В итоге на поколении I студенты-выпускники под моим руководством да и я иже с ними успешно защитили пять дипломных работ, расширяя функционал применительно к предприятию. Минусом поколения I можно назвать жёсткую фиксацию модулей в папках. Упомянутый ранее движок устраняет эту проблему и позволяет манипулировать сущностями как некими кубиками. Небольшое отступление. Замеченный мною недостаток MVC - необходимость обработки даных в два цикла: на этапе извлечения из базы контроллером и на этапе формирования визуального представления в шаблоне. Как-то нелогично: данные аки горячие пирожки - как только в руки попали, сразу надо с ними работать, а не перекладывать с места на место.
К сожалению, это особенность концептуального подхода к разделению функционального кода на модели и вид. Я лично для себя выбрал обходить это неудобство через композицию, когда я в декларативной форме объявляю средствами композитора, какую сцену я хочу собрать. Иначе говоря, сам вид сцены определяет однозначное использование того или иного функционала (модулей, маршрутизаторов, шаблонизации, других композиторов) для сборки композиции, а далее в процесс включаются совокупность методов нужных классов для конкретизированной выборки данных. Похоже на то, как корневая система у растений работает, впитывая влагу, ну или, если вам знакомы принципы выборки данных в поисковых алгоритмах (из кластера), тоже найдете достаточно много схожего. Вам никогда не казалось, что любая организация взаимосвязей между блоками кода, какими бы сущностями мы их не представляли или функциональным делением они ни обладали, на самом деле представляют собой ориентированный граф. И если посмотреть на этот вопрос именно с такой позиции, то можно заметить, что любое количество делений или выделяемых сущностей в структуре системы априори предполагают предел между количеством взаимосвязей (полный граф с рекурсией на узлях), то есть, вопрос архитектуры системы зависит, грубо говоря, только от того, куда и какие блоки мы разместим и какой интерфейс реализуем между выделенными блоками. Поэтому с точки зрения моделирования системы мне так импонирует выделение практически самодостаточных блоков кода (но применительно к веб-проектам это не совсем подходит, так как у нас минимум есть точка сборки, а это уже элемент централизации). Мне нравится ваш ход рассуждений. Вы красиво выстраиваете систему, от децентрализованного множества в строгую (с точки зрения формального определения) систему. Более того я сталкивался с этим (видимо это удел разработчиков, которые пытаются проектировать относительно сложные системы, а не только куски от общей задачи). Я использовал в подобном случае один, скажем так, "суперкласс" (ядро), экземпляр которого инициализируется сквозным образом через всю систему в области определения любого из множества классов (которые не являются дочерними и не расширяют базовый класс). Этот класс и является своего рода централизацией, обеспечивая возможность инициализировать произвольные экземпляры (доступные через собственные свойства). Какую логику вы закладывали в разделение функционала на все эти сущности. То есть насколько вы детализировали функуционал системы, выделяя под каждую из "деталей" отдельную логику? И какими принципами вы руководствовались в построении такой системы? Мне бы хотелось не просто увидеть реализованные коды, т.к. они мало что могут дать (я увижу лишь реализацию конечной логики), я хочу в первую очередь понять мотивацию в разработке именно такой архитектуры, ведь вы вполне могли реализовать целое множество других вариантов и других делений. Иначе говоря, мне более важен не конечный результат (система), а понимание пути, вами пройденного.
ребята, разрешите присоедениться к вашему общению! ) я тоже считаю, что идея крайне важна и действительно часто напарываюсь на то, что разработчики смотрят в код сразу, не поинтересовавшись идеей и сразу делают выводы типа "фу уг"... в общем, что хочу сказать ) пишу cms-ку, в которой основная фишка это именно идея, описать её до сих пор не могу взяться ( т.к. у меня не на столько красивая литературная речь, как у вас ребята да и пока думаю как сформулировать, соблазняюсь опять забраться в код и поковыряться с ним %)) давайте я вам выложу пару ссылок, если будет интерес, то задавайте вопросы - разжую всё на столько подробно на сколкь смогу %) а если еще и поможете потом сформулировать в нормальный ясный технический текст эту идею, то будет вам категорически благодарен! http://smart-core.org/wiki/Общие_принципы http://smart-core.org/wiki/Архитектура_(OLD) примеры кода уже можно считать устаревшми, но основная мысль никак не изменилась.
Фактически, это было переносом сущностей реального мира на объектный язык применительно к структуре академии. Изначально была поставлена задача «разработать сайт кафедры». Однако при переложении на коды проект, словно чёрная дыра, начал вбирать в себя задачи большего масштаба. Ниже приводится сжатая и обобщённая концепция развития протяжённостью одиночной разработки в пару лет. Что из себя представляет сайт кафедры? Набор страниц. Для него была взята модель из Softtime Framework (Category -> Page -> Paragraph -> Attachment (image)) - книга «PHP. Практика создания Web-сайтов (2 издание)» (помимо этого, в «общеобразовательных» целях на создание среды выполнения был задейстован ещё с десяток источников). Кафедре нужны дисциплины, но дисциплины - такой же набор страниц. Категория меняется на сущность «дисциплина». Каждую дисциплину ведёт свой преподаватель. Преподаватель - это пользователь. Пользователю нужно ограничить доступ к его дисциплинам. Цепь строится как User -> Policy -> Discipline -> Page -> Paragraph -> Attachment и сообщение читается как "пользователь, согласно политике доступа, может получить доступ к редактору дисциплины, манипулировать страницами, параграфами, вложениями". Но ведь кто-то должен редактировать основной раздел сайта? Поэтому, если в цепи подавить (пропустить) звено Discipline, получится цепь иерархии страниц основного раздела. По этому же принципу, если у Attachment подавить звено Paragraph, получится, что вложение прикреплено к странице. Итак, редактор структуры получается в виде кластера. Есть NULL-сегмент - главная и вложенные в неё страницы, есть сегменты дисциплин с собственными главными и подчинёнными страницами. Тут же самопроизвольно озадачился: сделаю сайт одной кафедре, а принцип-то универсален. Как на одном движке сделать несколько сайтов? Условия: преподаватель может читать дисциплины на разных кафедрах, следовательно он должен иметь доступ к разным сайтам. Как построить систему единого входа по логину и паролю? Реализовано то, что пришло на ум. В цепь между Policy и Discipline встроено звено Department (подразделение). Почему сюда? Пользователь может не иметь доступа ни к одной из кафедр, но может зайти в свой личный кабинет (ежедневник, личный центр межкафедральной навигации, свои дисциплины и т.д.). В то же время, если подавить звено Department, получится NULL-сайт (центральный) со своими пользователями и правами доступа (побочно - дисциплинами, но это можно утилизировать как «припаркованные» после очередной пятилетки модули, отсоединённые от кафедр). Теперь программой заинтересовался факультет, однако всё было готово. В Department введена иерархия parent-child. Концепция: любой сегмент уровня Department располагает типовыми инструментами управления учебным процессом и может решать задачи любого уровня иерархии (лаборатория, кафедра, факультет, институт, академия). На тему базового состава цепи был написан ряд статей, курсовая и дипломная работы. В итоге система ведёт себя так: при чистой установке имеем «тёмную лошадку» - сайт с одной главной страницей и панелью управления. Развернуть можно во что угодно: моделируем в панели структуру академии или другого предприятия (кластер подразделений), раздаём права на доступ к сегментам ответственным лицам. После установки в ВУЗ программировать не требуется - всё идёт через унифицированный интерфейс (минимум понятий, всё сведено к семи действиям над сущностью цепи - [вырезать, вставить], [создать, редактировать, удалить], [поднять, опустить]). Можно вырезать сегмент кластера Department, представляющий кафедру A и переместить его в факультет X или вовсе преобразовать в новый институт). То же самое с материалами дисциплин и самими дисциплинами - всё хозяйство в процессе путешествия по сайту складывается в контекстный буфер обмена. Для работы с буфером необходимо обладать разрешением RWD на источнике и RW на приёмнике. Система с кодовым именем «Ками» (яп. - чистый лист, бумага) превратилась в живое пособие для студентов: была учреждена специальная учебно-исследовательская лаборатория, в которой мои же сокурсники и подрастающие поколения могли прикоснуться к программированию PHP на том проекте, который бы являлся для них источником информации на парах в повседневности. Другие схожие специальности едва не перевелись на программное обеспечение, когда узнали, что у нас есть такая лаборатория с прикладным уклоном (но это скорее доля юмора - работы в лаборатории официально засчитывались как практические занятия по родственным дисциплинам). Благодаря собранному под задачи Ками из разных самоучителей обобщённому фреймворку, студенты почти не кодировали html - для них существовало понятие "список ссылок", которое преобладало в интерфейсе управления (вроде department list или attachment list). Как его стилизовать - задача верстальщика, причём исключительно средствами CSS. В общем, в то время мои мысли были заняты проработкой концепций и удержанием в памяти вероятных ситуаций с целью максимальной унификации, а не подробным описанием системы. В одиночку-то дипломная работа, как никак. В итоге - второе место на всероссийском конкурсе; пройденное с первого раза авторское свидетельство, несколько публикаций в сборниках и одна - в электронном научном журнале. Всё это было бы немыслимо без моего научного руководителя, которому я искренне благодарен за содействие и активное участие в формировании представления о структуре ВУЗа, многочасовые дискуссии (несмотря на занятость образовательным процессом), воодушевление на новые идеи, возможность публикаций и, в итоге, за моё становление как программиста. Система - это не только наборы кода и решение каких-то задач на листочках. Система - это всё, ради чего и для кого пишется код. Поэтому перенос объектов реального мира на ООП оказался столь увлекательным. Однако финансированию проекта не уделялось достаточного внимания и по окончанию обучения его участь стала для меня неизвестной. Сейчас работаю в другом направлении, однако оставшиеся фрагменты ядра позволяют быстро справляться с задачами и оценивать попавший в руки движок на предмет его слияния с такой же ручной поделкой Ками. P.S. Опаньки, снова три часа ночи А цепь упомянутых классов - это сущность проекта. Работа сводится к мета-сообщению в начале скрипта вроде "я работаю с уровнем Attachment и всем, что он может за собой притянуть и что может при необходимости проинициализироваться вместо него". На поздних этапах в базовый класс цепи Chain был введён Observer и модель событий, потому как инициализация выполнялась в три прозрачные для наблюдателя фазы, а авторизация и ещё какие-то процессы частично проходили по наследованию физических файловых путей. Это отдельная история, при желании расскажу, хотя у самого проект в памяти потихоньку «остывает».
Вот это ключевая фраза! Очень интересный у вас опыт, а главное, что крайне полезный с практической точки зрения. Я кстати в свое время тоже разрабатывал CMS в качестве дипломного проекта, но отказался где-либо участвовать (конференции и конкурсы). Знаете, те задачи, которые решают все системы отображения и обработки данных по определению имеют однотипные задачи. Из этого следует, что мы все (php-разработчики) решаем однотипные задачи в принципе, но весь интерес в том, что позиции рассмотрения вопросов у всех разработчиков разные. В связи с этим у меня возник ряд интересных предложений. Почему вы взяли за основу разрабатываемой CMF ZendFramework? И у меня возник еще один вопрос: почему вы рассматриваете разрабатываемую систему как семейство систем CMF (или все-таки CMS)? Не могли бы вы чуть подробнее описать логику двух моментов: маршрутизация и шаблонизация, к чему вы стремитесь в разработке, грубо говоря, по какому критерию идет разработка системы (удобство и скорость разработки/внедрения, удобство модификации, производительность, максимальная универсальность и т.д.)?
1) Более корректно будет спросить почему за основу был взят какой-то из существующих фреймворков. Дело в том, что в феврале этого года, я уже слишком остро ощутил, что огромную часть времени тратил на реализацию низкоуровневых библиотек, вместо того, чтобы заниматься бизнес-логикой самой цмс-ки. Именно по этому решил провести анализ существующих фреймворков и начать использовать какие-то готовые быблиотеки и решения... но надо отметить, что сначала всёже подумал, что смогу ограничиться только компонентами Symfony2, но чем больше вникал в суть их работы, тем больше понимал, что в итоге всё равно у меня получится сам фреймворк симфони по этому в мае окончательно перешел на симфони2. Почему выбрал именно симфони, а не например зенд или йии — это тема холиварная но замечу, что идею разрабатываемой цмс, можно было бы сделать наверно на любом каркасе... 2) Система получается именно CMF т.к. не имеет каких-то жестких изначально заданных концепций т.е. можно сконструировать то, что хочется даи с переходом на сф2 теперь есть возможность комбинировать обычные роутинги бандлов с движком. 3) Маршрутизация и шаблонизация , я наверно всёже перепостю сюда статьи с вики т.к. пока что другим языком объяснить мне будет сложно... Вся структура сайта имеет древовидный вид т.е. представляет из себя структуру виртуальных папок в которые добавляются требуемые функциональные модули, далее при запросе клиентом некого URI, движок начинает обход по заказанным папкам и подключает соответсвующие модули, собирается многомерный массив с данными, которые сгенерировали модули, затем запускается шаблонизатор, который по готовому массиву с данными собирает хтмл страничку. Для обеспечения гибкости в проектировании и отображении используется такие понятия, как «контейнер» и «наследование». Наследование применяется для того, чтобы добавив модуль в какую либо папку, он срабатывал и в папках включенных в родительскую папку, например чтобы отображать одинаковую шапку на всем сайте, создаём в корневой папке текстовый модуль и наследуем его вглубь. Контейнеры (они же «Блоки») это логическое объединение модулей, используется по большей части в шаблонах для отображении данных в заданных местах страницы. Концепция организации данных в Smart Core CMF схожа с концепцией организации структуры папок (директорий) и файлов в операционных системах. Например можно рассмотреть следующую структуру папок : Здесь видно иерархическую структуру папок системы (они помечены желтыми квадратиками), в этих папках могут находиться произвольные данные (по типу, как в операционных системах в папках хранятся разного рода «файлы»: текстовые, таблицы, картинки, аудио, видео, и т.д. а также другие «папки»), эти типы данных помечены как «ноды» бледно-зеленым цветом, а сами данные модулей помечены зеленым цветом. Например в папке «О компании» может находиться несколько «нод» (в Smart Core CMF «ноды» по смыслу похожи на файлы в операционных системах) в одной «ноде» может содержаться просто текст с контакной информацией, в другой карта расположения, использующая технологию Google Maps API, в третьей форма обратной связи для быстрой отправки е-маил сообщения администрации сайта и т.д. Некоторые «ноды» (или, как упоминалось выше, какбы «файлы») могут также иметь собственную организацию данных, как мы можем увидеть на примере папки «Каталог». Здесь нода, содержащая сам каталог, имеет собствунную структуру похожую на структуру папок всей системы, но в тоже время каталог является просто элементом встроенным в общую структуру папок системы. Так же каталоги могут иметь более тонкие возможности выбооки данных, например учитывая категорию товара, какие-то его характеристики, бренды, цены и т.д. Таким образом следуя этой модели данных, система может собрать тот набор данных, которые запросит пользователь, например: Мой сайт / Новости / Новости компании / Вторая новость. на практике подобныя ссылка может иметь следующий вид http://mysite.org/news/company/2009/10/10/second_notice.html В следствии обработки этого URI будут собраны следующие данные: * Модуль:Текстер - «Краткая информация о новостях на сайте» (при условии, если эта нода будет наследоваться из папки «Новости»). * Модуль:Новости - «Вторая новость». (собственно основные данные запроса, хранится в папке «Новости компании» в модуле «новости», извлекается запись «Вторая новость»). * Модуль:Текстер - «Футер» (т.к. эта нода наследована с главной «папки»). После обработки запроса ЧПУ и сбора модели данных запускается шаблонизатор, который на основании этих данных генерирует (X)HTML страницу, кторая уже отображается браузером пользователя сайта. На программном уровне алгоритм выглядит следующим образом: * parser() - метод разбирает строку запроса (URI) и собирает массив запрошенных папок, а также в случае, если часть запроса предназначена для какого-то модуля, то включает результат обработки парсера модуля. * getNodesList() - метод принимает подготовленный парсером массив с папками и собирает массив со всеми нодами, которые входят в эти папки, учитывая наследованные ноды. * buildModulesData() - метод принимает подготовленный список нод, и последовательно этому списку запускает модули, а результат их работы помещается в массив ЕЕ (Essential Elements) * Template() - шаблонизатор на основе готового массива ЕЕ, генерирует HTML страницу. Добавлено спустя 23 минуты 13 секунд: Изначально была цель создать логичную систему в которой данные нормально отделены от представления. Концепцию этого движка мы продумывали с моим хорошим товарищем несколько дней вели эмоциональные дебаты и генерировали идеи в принципе с тех времен мало что изменилось и было сделано несколько движков на этой концепции, но во всех, кроме той, что я развивал до февраля, были архитектурные проблеммы в плане кода. Исновными критериями для меня являются в приципе всё вами перечисленное честно без шуток и сарказма. Т.е. реально я пока не нашел задачи, которая бы не решалась в рамках этой концепции (папки, ноды, модули, блоки). Вообще сам движок предоставляет только механизм комбинирования результатов работы модулей, а весь функционал описывается в модулях, по этому тут уже как разработчику угодно, такие возможности система и получает. Разумеется есть некий набор типовых модулей, с помощью которые решаются большинство рутиных задач, а процесс создания новых модулей будет достаточно простым. Производительность это вообще интересная тема дело в том, что создание универстальных систем требуем достаточно много вычислительных ресурсов т.к. надо предусмотреть слишком много нюансов но в своей системе я всёже уверен в плане скорости т.к. в прототипе уже были опробованы несколько методик кеширования, которые позволяют очень сильно ускорить генерацию ответа.
Интересное решение. Я ознакомился с приведенной информацией на вики. Бегло просмотрел инклюды, уловил ZF, поэтому упомянул о нем. Почему мне был так интересен вопрос маршрутизации и шаблонизации - наверное, потому что это довольно интересные в плане реализации узлы, по крайней мере, я видел за свою практику уже несколько совершенно различных и оригинальных решений (которые не являются образующими от каких-либо классических подходов). Насколько я понимаю, в данном случае маршрутизация работает по принципу прямой адресации, судя по URL к модулям-исполнителям, которые по ходу дела наследуют по всему каскаду вложенности общие элементы (с присущими им выборками данных). Скажите, а сталкивались ли вы с задачей множественного отображения в рамках одного представления, допустим, когда на одной странице генерируется несколько различных блоков, имеющих различные параметры (с переменным их количеством): например, представьте сайт, где на главной странице организована витрина в виде полок с книгами, дисками и журналами, за каждую полку отвечают разные модули (разная бизнес-логика), и каждый модуль имеет входные параметры сортировки, - мне хотелось бы более тонко понять идею маршрутизации в данном контексте, как с точки зрения маршрутизации будет выглядеть такой составной URL? mysite.org/polka_1/param_1/val_1/param_2/val_2/.../polka_2/param_1/val_1/.../polka_3/param_1/val_1/.../ [пример из классики] И правильно ли я понимаю, что на каждый узел из URI (разделитель /) движок делает обход модулей для подключения?
можно по подробнее, что озачает "принцип прямой адресации"? впервые слышу такую формулировку и не решусь догадываться, что это значит хотя скорее всего что-то знакомое, просто по дргому названо на тему "множественных отображений" (тоже незнакомая мне терминология), пример с яндекс каталогом подходит? например запрос: http://yaca.yandex.ru/yca/geo/Russia/Siberian/Novosibirsk_R ... _Services/ можно разложить по полочкам: /yca/ - здесь папка, где подключен модуль каталог. geo/ - это указатель на некую структуру категорий внутри модуля каталога. (такимиже "указателями" являются в данном примере: cat и synt2) следом за geo указана строка Russia/Siberian/Novosibirsk_Region/Novosibirsk/ следовательно будет сделана выборка в древовидной базе geo. аналогично с "cat". в итоге результат будет содержать только те записи (в данном примере - описания сайтов), которые в обязательном порядке входят во все 3 древовидные структуры. надо обратить еще внимание, что порядок следования "указателей" не имеет значения, например запрос: http://yaca.yandex.ru/yca/synt2/Goods_and_Services/geo/Russ ... Computers/ выдаст нам совершенно тотже результат! Данный механим отсутствует на уровне ядра системы, но он в некоторой мере уже реализован в компоненте "юникат", разумеется как только допишу базовый функционал после рефакторинга, то сразу вернусь к развитию этой либы На счет обработки движком запроса УРИ, да, сначала собирается только список запроценных "папок" (разумеется, если он некорректный, то на этомже этапе выдаётся 404), затем по сформированному списку "папок", создаётся список "нод" и только потом ядро уже выполняет модули подключенные в этих нодах и результат их работы складывает в нужное место. Только я бы не сказал, что это "обход модулей"... ведь выполняются только те модули которые требуются для генерации ответа клиенту. Вообще вот здесь http://digi.tw1.ru/ выложена демка, там можно покрутить папки, поподключать ноды, поперемещать их между блоками и т.д. но там выложен предшественник и разумеется далеко не всё работает, но прицнип движка вполне можно ощутить
Хм. Под прямой адресацией (прошу прощения за терминологию, просто за время разработки привык к подобным терминам в общении с коллегами) я понимаю однозначное (прямое) определение в запросе модуля и параметров к нему в рамках иерархии системы. Совершенно так, как вы указали в примере с каталогом яндекса. А под множественным отображением я имею в виду ситуацию аналогичную с каталогом, но когда список выдачи не один, а их несколько, и у каждого персональные параметры отображения (когда один запрос содержит по сути несколько совершенно различных точек обращений к разным модулям с разными параметрами), опреденные пользователем (чаще всего это фильтры, например, в сравнениях списков, но там они реализованы немного не по такому принципу, собственно поэтому меня заинтересовал этот вопрос). В любом случае, скачал коды, изучу реализацию. Весьма занятно
А вы можете показать в действии "множественное отображение"? а то на словах, можно много чего самому себе придумать Коды смотреть - это хорошо ) но скорее всего лучше изучать текущие наработки, а не замороженные... хотя и в текущих пока еще далеко не всё сделано... Официальная репа проекта тут https://github.com/Smart-Core/ В частности логика сборки находится вот тут https://github.com/Smart-Core/SmartCoreEngineBundle/blob/ma ... roller.php Добавлено спустя 6 минут 25 секунд: На счет "прямой адрессации"... ммм... возможно где-то так оно и есть хотя я бы не стал применять такую терминологию в рамках этого движка... может быть было бы точнее сказать "динамическая маршрутизация с возможность наследования" А вообще, если вы вникните в логику, которая в принципе достаточно простая, тут всего то 4 сущности, притом что "нода" является всего навсего точкой подключения "модуля" то может быть попробуете описать эту идею в понятном для людей виде? ) чтобы людям действительно было понятно как оно рабоатет... а то почему-то в того описания, что я сумел выжать из себя - никому ничего не понятно %)) а если я напишу тоже самое, только лично и чуть чуть поменяю слова местами, то почему то понимание больше возникает %)
Взгляните на страницу того же Яндекс.Маркета (первое, что пришло на ум для наглядного представления): http://market.yandex.ru/model.xml?CMD=-RR=9,0,0,0-PF=180194 ... &hid=91013 На странице есть блоки "Популярные модификации" и "Интернет-магазины", в них применена сортировка, скажем так, "по-умолчанию". Иногда пользователю может потребоваться не переходя непосредственно по ссылке в раздел Популярные модели или Интернет-магазины, применить сортировку к списку или фильтр. Если эти блоки формируются абсолютно разными нодами, которые могут логически не быть потомками одного общего родителя и вообще не быть никак связаны между собой, как бы вы подошли к решению задачи отображения с разными параметрами этих блоков, каким вы считаете правильное ее решение? Я сам сталкивался с подобным и решал классикой жанра -> контроллер/параметр/значение/параметр/значение, это своего рода HMVC - надстройка над прямой однозначной адресацией, так как над блоками формируется новый контроллер (возникает избыточность, но в большинстве случаев вполне допустимая), но впоследствии перешел к использованию компонент.
пример не тот, что вы описываете! дело в том, что зедсь все параметры передаются GET очередью в http://market.yandex.ru/model.xml притом здесь реализована своя логика, в частности запрос можно разложить на следующие части: Код (Text): http://market.yandex.ru/model.xml ?CMD= -RR=9,0,0,0 -PF=1801946~EQ~sel~1871127 -PF=2142398356~EQ~sel~276273303 -PF=1801946~EQ~sel~1871127 -PF=2142398356~EQ~sel~276273303 -PF=2142372765~EQ~sel~337419139 -PF=2142372765~EQ~sel~318739075 -VIS=470 -CAT_ID=432460 -EXC=1 -PG=10 &modelid=7309414 &hid=91013 Как видим, всё толкается в CMD, значит на этом сайте есть некая библиотечка, которая отвечает за формированние данной строки из параметров, которые ей передадут различные модули, также эти же модули могут запрашивать какие-то свои параметры с этой либы. Думаю именно так у них и сделано... и это разумеется тоже можно сделать в движке хотя у меня пока таких задач небыло, но предусмотреть на будуще очень даже надо будет (пойду запишу в TODO )
Я привел пример не с реализацией принципа, а с тем, чтобы вы поняли, что я имею в виду под отображением разных блоков с параметрами. В маркете не используется true ЧПУ =), а совокупностью get можно сформировать любые параметрические запросы, это же очевидно. offtop: Уже утро, я сегодня не спал совсем, налью чашечку кофе, пойду читать коды =)
В приципе да, но в любом случае надо централизовать этот процесс, например создать модуль что-то типа CustomRequestParams, цепляем его в ту папку откуда у нас должны считываться параметры, после этого движок сам будет передавать ему запрос от юзера и будет собран список параметров. Ведь в движке сейчас обработка всех роутингов идёт ДО начала выполнения модулей, по этому предоставить модулям их наборы параметров будет достаточно просто но всё равно модули скорее всего должны будут настроены на считывание/запись параметров через этот модуль... тут подумать еще надо как красивее сделать можно Добавлено спустя 54 секунды: а вы можете описать ваше решение?
Я не использую страницу как конечное значение работы движка, я оперирую понятием "сцена" или "композиция". Сцена (то что обычно подразумевается как страница) при первом запросе http://mysite.org подгружает основу с FrontEnd частью. Затем пользователь своими дейсвиями заставляет через FrontEnd реагировать BackEnd и обратно ответом через FrontEnd видоизменять композицию и сам FronEnd динамически загружая и выгружая участки JS. То есть композиция полностью трансформируется через связку FrontEnd-AJAX-BackEnd. При этом я обращаюсь исключительно точечно к компонентам, а разбор урла происходит не по единой схеме, а совершенно индивидуально в зависимости от "поведения" того куска логики, к которой происходит обращение. Иными словами единого правила вообще не существует, все строго индивидуально, но основано тоже на 4х сущностях: шаблонизатор, композитор, маршрутизатор и ядро модуля - это все т.н. компоненты, они совершенно автономны и никак не зависят друг от друга напрямую, я лишь складываю их в нужном порядке для обесечение поведения. Я сейчас занимаюсь разработкой этой концепции, как наиболее удобной для себя, мне кажется, это неплохая альтернатива HMVC, я выше по тексту немного расписывал саму идею.
ага читал ) но не понял до конца... а у вас есть демо с бак-енд админкой, чтобы покликать мышкай, посмотреть на сколько всё интуитивно понятно?
У меня есть front-end с разработкой системы, в моем случае то, что вы подразумеваете под BackEnd - это ERP и CRM, я не думаю, что она для вас представляет интерес. Залью обновления на сервер и скину ссылку в личку, покликаете, заодно впечатления от работы морды сайта расскажете =) Например, пользователь интернет-магазина кликает Купить товар, происходит обращение к точке сборки -> ядру -> раутеру -> ядру модуля покупок, в ответ FrontEnd получает инструкцию и меняет счетчик на странице, без необходимости перезагрузки. Затем пользователь совершив покупку выходит из под своей учетной записи - опять же, происходит обращение к модулю доступа, он логирует событие, обнуляет все данные, присущие сессии и отправляет инструкцию во FrontEnd, в итоге происходит видоизменение композиции, выгружаются лишние участки кода, трансформируется интерфейс на гостевой. Пользователь уже неавторизован, ничего не перезагружалось, система не отрабатывала целиком, сработал лишь маленький кусок кода. P.S. Но это не рендеринг на уровне FrontEnd, это все-таки именно видоизменение. Похожий принцип используется вконтакте сейчас.
Хм... ну так это же обычный аякс... например на старом движке можно было выполнять такой запрос http://digi.tw1.ru/ajax/5/get это означаает, что с ноды номер 5 надо получить ответ с экшена get. По аналогичному принципу можно обратиться к любой ноде, разумеется движок сам смотрит права доступа юзера. Я к сожалению недостаточно уверенно чувствую себя в явяскрипте, джиквери и т.д... по этому в новой ветке к разработке аяксовой админке присоеденился один товарищ но реализация начнётся толкьо после того, как я сделаю в движке работу с правами доступа и устаканю API работы с модулями. Добавлено спустя 1 минуту 57 секунд: да да, идея отличная! мы тоже будем делать админку как в друпале, по типу http://cms_drupal/#overlay=admin/people/permissions но здесь логика движка и клиентская юзабельнсть только дополняют друг друга
Все верно, я и говорю о взаимодействии FrontEnd и BackEnd через AJAX c целью видоизменения композиции. Кстати по поводу терминологии "движок", я даже не знаю как правильно сказать... хм... я сейчас начал работать над своим собственным проектом не на уровне конструкций движка (CMF) или даже фреймворка, а, наверное, несколько глубже (я правда не знаю как это сформулировать =) ), так как FW предполагает определенные правила (тот же Zend, несмотря на то, что он гибкий, у него есть определенная структура и достаточно четкие принципы структурирования систем на его основе, как минимум основные компоненты предполагают определенное использование и в основе всего классика), но в процессе долгих размышлений над тем, что же для меня окажется наиболее удобным, я выбрал наиболее гибкую схему произвольных структур в системе (так у меня разработка получается более гибкой и более быстрой). То есть с одной стороны, я все же использую какой-то прототип конструктора, но с другой стороны, в этом конструкторе нет четких правил, как-то так. Я сейчас почищу коды от всей логики своего основного проекта и оставлю только саму суть, покажу вам идею именно в чистом коде, так сказать, на примере "Hello World" =) Абсолютно согласен! AJAX вообще хорошая штука при правильном применении.
Вообще с нетермением жду! Но кстати, если для создания проекта на каком либо движке, требуется менять код движка, то это нехорошо... всёже бизнес логика должна находится рядом с платформой, а не внутри неё... По поводу терминологий, я на самом деле касательно своего проекта использую в разговорной речи 2 термина: "движок" и "цмс". А вот внутри проекта есть сервисы (Dependency Injection Container или Servive Container), вот они уже имеют префикс "engine." например через сервис engine.site мы получаем объект, через который можно выяснить всё кстательно текущего сайта, через engine.user получаем доступ к текущему юзеру и т.д...
Все зависит от аудитории разработчиков, на которую расчитана система, и от проектов, под которые она заточена. В моем случае аудитория - я сам, и проекты на этом коде тоже индивидуальные, поэтому экспериментирую от души, без оглядки на мнения, это определенная степень свободы, которая была недостижима ранее, не может не радовать =) Тематика топика же подразумевает некоторый обмен опытом на уровне парадигм применяемых разными разработчиками при проектировании систем, речь не идет в данном случае о ведрении open source и сопутствующие при этом нюансы, проблемы сопровождения и т.д., даже не смотря на то, что вы взялись за разработку подобного решения. Я все же предполагаю, что в данной ветке форума мы делимся представлениями принципов работы тех или иных механизмов. Как я уже говорил ранее - каждый разработчик все равно реализует те или иные принципы по-своему. К тому же, я считаю, что такое свободное ковыряние в различных кодах систем, поиски и сравнение совершенно разных подходов и вариантов решения одних и тех же задач - это лучший способ развития и расширения кругозора, более глубокого представления процессов. Где и когда еще, кроме как в свободное время, возникнет задача: "А не сравнить ли мне парочку FW, разные реализации интерфейсов, выбрать все лучшее из них, пересмотреть все это, придумать что-то новенькое и написать свое?" Главное вовремя переводить just for fun в основной вид заработка и профессиональной деятельности.