В связи с тем, что достаточно много время потратил на написание всяких движков, решил изложить свое представление о проектировании CMF.

Буду стараться излагать мысли кратко, понятно и абстрактно дабы сразу не запутаться и постепенно перейти к мелким деталям.

Каждая страница веб-сайта имеет свой уникальный адрес. Как правило, адреса страниц динамического раздела сайта являются идентичными друг другу и различаются лишь параметрами, передаваемые скриптам.
Примером этого может послужить раздел новостей. Адреса страниц новостей на Вашем сайте могут выглядеть:

Код

news/2.html, news/54.html ...

или

Код

news5.htm, news25.htm ...

Несложно понять, что с помощью регулярного выражения мы можем написать шаблон под который попадут все адреса страниц того или иного раздела.
Для вышеприведенных примеров это будут соответственно:

Код

/news\/([1-9][0-9]*)\.html/

и

Код

/news([1-9][0-9]*)\.htm/

Каждому такому шаблону можно строго привязать список действий, которые будут происходить в случае запроса страницы с адресом, попадающей под шаблон.
Физически действие представляет собой программный код (в идеале, класс), так называемый контроллер. На основании полученных данных (из адреса, формы и пр.), контроллер может решать основные задачи:
1. Подготовить данные для формирования конечной страницы.
2. Произвести какие то операции, не связанные с отображением данных (запись в БД, создание сессии, проверка авторизации и пр.)
Финальной точкой работы контроллера является возврат кода завершения операции, анализируя который движок "подсунет" пользователю то, что он должен увидеть.
Шаблону может соответствовать не один контроллер, а несколько. В таком случае, контроллеры будут поочередно срабатывать, передавая данные друг другу.
Также к каждому контроллеру привязаны шаблоны HTML-блоков (или других объектов) из которых будет строиться конечная страница. Естественно, контроллер может реализовывать интерфейс любого готового шаблонного движка.

Итак, основная часть ядра системы условно должна представлять собой механизм анализа адреса запрашиваемой страницы и запуска соответствующих действий (контроллеров). Все остальное (БД, сессии и т.п.) можно реализовывать в виде "обособленных" модулей.

Это сообщение отредактировал(а) skalex - 10.1.2006, 21:18

По поводу концепции могу сказать следующее: система управления контентом должна чем-то выделяться среди других ей подобных. Я бы главным качеством CMS назвал гибкость:

• Большое количество дополнительных модулей
• Взаимодействие с другими продуктами
• Гибкость самих модулей

По поводу второго пункта могу привести конкретной пример: есть такая CMS Mambo, ныне Joomla, ныжно было приспособить для работы с мощным форумом. Нашелся такой хак для нее, который позволяет ей работать в связке с phpbb: общие пользователи и общие сессии.

skalex работал над твоей идеей, не живая она ИМXО...

Сначала рссмотрим ссылку, эта штука с одной стороны имеет стандарт, с другой не красиво иметь полные URL, ЧПУ гораздо приятней, но не на каждом сервере имеем. URL адресует конкретную страницу на сайте и вообще за его пределами.

Отсюда столкнёмся с двумя проблемами если хотим строить ссылки: как генерить ЧПУ если сервак их поддерживает или просто ссылки если нет? Вторая: как адресовать из разных страниц другие страницы, например из новостей ссылку на некую статью, при этом контроллер статьи может поменяться, изменяя свои принимаемые параеметры.

Отсюда я вывыл простую концепцию, где каждый ресурс известный в системе имеет уникальный идентификатор и параметры. Например хотим адресовать новость из шаблонизатора, то:
{linkto(#news#, #some title or id#)}
На это место уже встанет ссылка вида:
.http://domain/index.php?act=show-news&bytitle=some...
или
.http://domain/news/some...

При этом конкретная страница ничего не знает о ресурсе и где он находиться, она знает его идентификатор и имена параметров которые он должен принять. Некий обьект ResourceMap сгенерит ссылку изходя из настроек. Сам же ресурс может со временем кардинально поменять свой URL или вообще переехать на другой домен, никого это не коснёться.


Далее о построении страницы. У тебя я помню модель процессов, где во внешнем XML задаёться список "процессов", что будут выполняться один за другим. ИМXО это не удобно, в том плане что на самом деле свободы нет, связывая процессы друг с другом мы не указываем где что генериться и что происходит, а процессы должны уже "знать" с кем они будут иметь дело. Ну мне так показалось...

У себя реализовал триаду Model-View-Controller, где на задачу контроллера выполо ещё инициализировать вид и модель из-за природы PHP. Удивительно краткий index.php подгружает конфиги, собирает окружение (определяються языки пользователя + системные пути до переводов, дефолтовых и базовых страниц), создаёт базовый контроллер (MainPageController). Он модели не имеет, только вид, что грузит основной шаблон страницы, это заголовок, подвал, общие стили, также размечаються места под дочерние обьекты вид (меню, контент, подсказки, окна ит.д.).

Каждый контроллер знает о своим параметрах из $_REQUEST и принимает решение что делать, в частности MainPageController по act решает какой контроллер для контента подгрузить. Выполняеться это в switch'е. Грузяться и другие контроллеры, например меню, анонсы и прочие рюшечки, все они собираються в коллекцию дейтей контроллера. Каждый подгруженный контроллер в свою очередь грузит необходимые классы, создаёт обьект вид(обязательно) и модель(если имеет). В итоге получаеться этакое дерево контроллеров, которое в принципе не нужно

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

Всё о чём говорил выше уже реализовано и не плохо работает здесь: http://eurogates.ru/index_.php
Пока долбаная агава своим прокси мешает жить, подменяя в заголовках кодировку, страницу отдаю как UTF-8 (сайт на многих языках, опредляеться динамически по Accept-language, можно задать GET параметр lang, есть пока ru и en), прокси подменяет их на win1251. Видим пока тестовую страницу, над сайтом ещё работать и работать

В кратце там пока три MVC: меню, контент и вся стрница в целом реализованы. К этому всему добавим море "закулисной" работы, например генератор словоформ для правильных переводов (особо касаеться русского), карта ресурсов что говорил выше, менеджер общих(shared) обьектов (этакие именованные сервисы), парсеры, анализаторы и многое другое

Sardar


ну так давай оживлять! вернее, приходить к верному решению.

Пока о ссылках ...

Не совсем понял что ты имеешь в виду под фразой "как генерить ЧПУ если сервак их поддерживает". mod_rewrite? Если да, то сорри, избаловался ... Привык к нормальным сервакам.

Ну а что мешает сделать настройку "Поддержка ЧПУ"? И вообще тут еще вопрос маркетинга (продвижения сайта) надо учитывать.

Как адресовать? Возможные варианты:
1) В CMF надо иметь класс, который возьмет на себя всю работу по генерации ссылок.
2) Каждый контроллер сам генерирует свой URL. Если необходима генерация "левой" ссылки внутри текущего контроллера, то создаем экземпляр необходимого контроллера и обращаемся к соотв. методу.

Пока не знаю как это сделать в специфических шаблонизаторах ...

По поводу остального позже ...

Нам стоит делать с расчетом на нормальные серваки. Хотя mod_rewrite конечно такая вещь, что для нее настройку можно и довольно легно сделать, на тот случай, если использование mod_rewrite нежелательно почему-то. Впрочем концепция не только в ссылках заключается ведь...

Wowa, думаю что самое простое решение, самое надежное. Для простейшей работыс mod_rewrite предлагаю парсить все данные как аргументы разделенные слэшем. Если не стоит mod_rewrite - заюзаем error_document - хотя сначало нужно обсудить как такой метод скажется на поискавиках (об этой оптимизации тоже забывать не стоит).

Поясню про свой взгляд на передачу данных движку:

Есть запрос: /Products/Presentation/VingradCMS/Tehnology/Chapter09.xml

Разбиваем. Получаем массив аргументов. Обрабатываем. Вызываем страницы Products -> Presentation. подгружаем модуль презентаций. Выбираем проудкт VingradCMS. Открываем презентационную страницу из раздела Tehnology (используемые технологии), раздел 9.

Подводные камни: поскольку дерево документов может быть разной длинны, мы в данном случае связываем дерево в базе по ключам первичной директории, но может возникнуть глюк с тем что аргументы передаваемые в модуль, могут соответствовать поддокументу (например если в Presentation есть документ VingradCMS), тогда будет загружен не документ VingradCMS а не страница с модулем Presentation. Хотя шансы на такое совпадение малы, нужно это обдумать.

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

Концепция в адресации компонентов системы, где имеем ресурс и его аргументы, а как это будет построено не важно. Таким образом можно строить валидные изменяемые со временем (перезды и т.п.) ссылки. Неймспейсы мне не пригодились, ресурсы просто перечислены в карте в XML

Тут народ обсуждал тему CMS есть что почитать и сделать выводы
http://phpclub.ru/talk/showthread.php?s=&a...mp;pagenumber=1

Это сообщение отредактировал(а) B2_Russia - 4.2.2006, 00:50

ссылы идут в makeUrl
а вот с распознаванием.. это будет в system.php например... хех TODO