Концепции современной CMS

[2NetFly]

Концепции современной СУК

Продолжительное время интересуюсь системами управления контентом, впервые опробовал свои силы в данном направлении около 4,5 лет назад, когда соорудил процедурное подобие CMS на перле. Спустя некоторое время появились наработки ООП системы, началось знакомство с HTML::Template, TT, lxp, Mason и прочими популярными в то время разработками. Все время работа велась не над CMS, как таковой, а над неким инструментом, позволяющим создавать веб-приложения любого уровня сложности (в том числе и CMS).

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

Для начала я хотел бы поговорить о недостатках современных СУК и поделиться своим мнением по этому поводу. Итак недостатки:

1. Попытка создать систему, которая "проста и доступна для использования человеку, не знакомому с программированием". Как следствие, чрезмерное акцентирование внимания на разработке средств инсталляции, "интуитивно понятных редакторов и интерфейса", преднамеренное упрощение системы за счет лишения ее функциональности.

2. Проектирование и разработка не с того конца (сам так ошибался), т.е. первоочередное решение таких второстепенных задач, как поддержка многоязычности, стилей, тем и т.д.

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

4. Полная зависимость модулей друг от друга, когда этого не нужно, и невозможность интеграции модулей между собой там, где в этом действительно возникает необходимость.

Это только малая часть того, о чем можно написать.

Свое виденье системы я вкратце описал в данной теме в 16 сообщении: http://phpclub.ru/talk/showthread.php?s=&threadid=58641#post404069 .

 

[antiportal]

1. Попытка создать систему, которая "проста и доступна для использования человеку, не знакомому с программированием".

На самом деле вопрос о всяких средствах инсталляции и автоматизации -- это только часть проблемы стремления к out-of-the-box. Если СУК представляет собой законченный продукт, а не технологию, то она должна обладать автоматической системой инсталляции просто потому, что это удобно (например, шелл-скрипт или веб-установка).
Вопрос о затачивании интерфейса под секретарш в ущерб функциональности решается либо созданием второго, чисто служебного бэкофиса для администратора, либо написанием клиентского win-приложения со всеми удобствами для юзеров.

2. Проектирование и разработка не с того конца (сам так ошибался), т.е. первоочередное решение таких второстепенных задач, как поддержка многоязычности, стилей, тем и т.д.

Такими путем в основном идут open source разработки (часто бывшие "под себя"). Для профессионалов такой проблемы просто не существует.

3. Недостаточная гибкость и скудные возможности кастомизации.

Для кого скудные? Для php-программиста, который будет ставить систему заказчику или для юзера-редактора? Опять же продуманные коммерческие системы обладают мощным продокументированным api.

4. Полная зависимость модулей друг от друга, когда этого не нужно, и невозможность интеграции модулей между собой там, где в этом действительно возникает необходимость.

Это следствие непродуманной архитектуры, api и часто недостаточной абстрации.

 

[2NetFly]

Я имел в виду различные open source разработки, такие как phpNuke, thatware, xoops и т.д. Коммерческим разработкам зачастую свойственны проблемы обратного характера %)

Если говорить о системах, ориентированных на работу с БД, мне кажется хорошим решением было бы разделение классов не те, которые занимаются отображением информации (блоков) и те, которые делают все остальное.

 

[Кром]

Я так понимаю мы рассматриваем недостатки с точки зрения разработчика?

1. Обычно система прирастает системными модулями и основным функционалом, а уже потом редакторами и т.д., поэтому не вижу логики согласно которой система будет упрощаться. Она скорее разбухает и делается сложнее. Так что не охватишь беглым взглядом - приходится лезть в руководство.

2. Ну, это перекосы на местах. Да, бывают, но все поправимо.

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

4. Это - обычные ошибки проектирования. Проблема не CMS/CMF, а непосредственно разработчика. Разработчик набирается опыта, проблем такого рода становится меньше.


Есть ли у вас вопросы действительно характеризующие проблемы пострения CMS?

 

[tony2001]

я прошу прощения, вы можете обсуждать не СУК, а CMS ?
спасибо.

 

[antiportal]

2NetFly

мне кажется хорошим решением было бы разделение классов не те, которые занимаются отображением информации (блоков) и те, которые делают все остальное

Под классом обычно подразумевают программный код, а это значит, что при таком варианте теряется независимость логики представления. "Блоки", имхо, вообще являются пережитком *nuke платформы. Используя современные шаблонные технологии можно без проблем отказаться от блоков (в их "нюкопонимании") как прокладки ("интерфейса") между классом модуля и шаблонизатором.

Я могу привести пример из знакомой мне реализации CMS:
- как у всех нормальных систем (кроме нюки и прочего барахла) есть дерево материалов
- для каждого элемента дерева назначен шаблон и модуль
- в шаблоне любого элемента можно подключить другой элемент через его unique id (+ переназначить для него шаблон, если необходимо)
- в любом шаблоне доступны стандартные функции API (например, функция подключающая статический файл и т.п.)

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

 

[2NetFly]

А как реализуется интеграция модулей друг с другом? Если говорить о CMS, в моем понимании идеальным является тот вариант, когда модуль максимально независим от всех остальных модулей, но реализован с соблюдением некоторых правил, что позволяет связать его с другими модулями. В качестве примера можно привести модули комментариев и оценки. При установке пользователем, например, фотогалереи, последняя ничего не знает о наличии модулей комментариев или оценки. Однако, пользователь путем нехитрых манипуляций над шаблонами может включить возможность комментирования, просмотра комментариев, оценивания, просмотра оценок, естественно, без правки кода.

Это я говорю о системах, основанных на блоках (кстати, блоки любого уровня вложенности – это довольно мощный механизм). А что в этом плане предлагают более серьезные системы?

-~{}~ 17.11.04 12:59:

Кстати, какие из существующих CMF / CMS (в первую очередь интересует CMF) заслуживают внимания? Довольно много всего перепробовал, заинтересовал разве что Krysalis.

 

[_RVK_]

ИМХО, проограммисту имеет смысл говорить только о CMF, так как нормальная CMS(универсальная) может быть только коммерческая.

Я, разрабатывая свою, CMF преследовал 2 главные цели:
Храниение структуры и настроек в едином месте.

Пришел к древовидной структуре, где каждый элемент ветви имеет свои свойства.

Для CMF написан простенький интерфейс, с помощью которого я создаю дерево, и задаю нужные настройки для элементов ветвей (модулей). Так же есть класс (интерфейс, API, как хотите...), который эти настройки получает.
Проблема универсальности решается легко. Модули никак не зависят как друг от друга так и от всей системы вцелом, и могут работать совершенно автономно, просто нужно соблюдать определенные требования.
Связь между модулями тоже легко осуществима, т.к. любой модуль имеет доступ к свойствам любого другого модуля, зная его имя.

 

[antiportal]

2NetFly

А как реализуется интеграция модулей друг с другом?

Автор оригинала: Diesel
Связь между модулями тоже легко осуществима, т.к. любой модуль имеет доступ к свойствам любого другого модуля, зная его имя.

А в остальном модули действительно независимы.

Если брать интеграцию системы комментариев к новостям:
- создаем элемент с произвольным шаблоном для отображения/добавления комментарев
- модуль комментариев через api узнает id атомарного элемента (новость с id 123) и его основной модуль (news)
- комментарий сохраняется в таблицу с pid 123 и указанием типа news

 

[2NetFly]

Если брать интеграцию системы комментариев к новостям:
- создаем элемент с произвольным шаблоном для отображения/добавления комментарев
- модуль комментариев через api узнает id атомарного элемента (новость с id 123) и его основной модуль (news)
- комментарий сохраняется в таблицу с pid 123 и указанием типа news

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

Впрочем, в моей системе и класс "новость" и класс "комментарий" являются наследниками класса "документ", в котором реализована практически вся функциональность. Физически записи хранятся в одной таблице и это существенно облегчает разработку. Думаю, не у одного меня такая реализация %)

-~{}~ 17.11.04 18:57:

Надеюсь, хоть кому-то будет интересно %)

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

Как минимум две трети задач, с которыми сталкиваюсь я (думаю, это верно и для веб-программирования в целом) сводятся к получению, обработке и отображению информации. Я работаю исключительно с БД (mySQL или PostgreSQL), поэтому в моем случае под получением информации подразумевается ее выборка из БД. Исходя из этих фактов, я попытался создать систему, которая облегчила бы мне это задачу.

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

ООП в связке с реляционными БД часто накладывают искусственные ограничения и усложняют использование и взаимодействие классов. Мне показалось удобным вынести в отдельные классы методы, которые занимаются получением и обработкой информации (методы отображения). Чаще всего суть этих методов состояла в выполнении запроса к БД и последующей обработке данных. Затем был создан класс, умеющий строить блоки на основе заданного шаблона и результата выполнения метода отображения. Затем механизм, позволяющий вызывать методы построения блока непосредственно из шаблона. Это все было скреплено с ядром, содержащим классы для обработки ошибок, работы с бд, автоматизации выполнения запросов, регистрации обработчиков, проверки параметров и т.д. Плюс механизм, похожий на смарти.

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

В теории все звучит достаточно неясно и туманно, на практике же гораздо проще. Посему привожу ссылку на страницу, где я в двух словах описал принцип работы системы.
http://feotast.net/wcp.html

-~{}~ 17.11.04 19:02:

Постарался максимально упростить пример, однако, все равно вышло довольно сложно. Т.ч. если интересно и что-то не понятно – спрашивайте.

 

[antiportal]

Для этого модуль комментариев использует оговоренный метод модуля новостей.

Почему бы не стандартизировать метод нахождения атомического элемента материала?

Впрочем, в моей системе и класс "новость" и класс "комментарий" являются наследниками класса "документ", в котором реализована практически вся функциональность.

То есть этот общий класс предоставляет api для материалов.. логично =)

Физически записи хранятся в одной таблице и это существенно облегчает разработку. Думаю, не у одного меня такая реализация %)

А как же нормализация и т.д. Какие все же плюсы в таком хранении? Я знаю только практику по таблице на модуль (для сложных, например форума, соответственно 2 и более).

 

[2NetFly]

Почему бы не стандартизировать метод нахождения атомического элемента материала?

Он стандартизирован %) Возможно, я недостаточно ясно выразился.

То есть этот общий класс предоставляет api для материалов.. логично =)

Не совсем так. Документ наследуют другой класс (Х), а вот он и выполняет эти задачи. Так же наследником класса Х является класс медиафайл с единственным используемым мной в данный момент классом-наследником изображение.

Пока что мне этого достаточно. Класс "изображение" используется для хранения иконок для новостей, обложек для альбомов в мр3 архиве, изображений, приаттаченных к публикации и т.д. Так же просто реализуется галерея – наследник класса "документ" представляет собой "морду" галереи, а "изображениe", соответственно, принадлежащие ей изображения.

А как же нормализация и т.д. Какие все же плюсы в таком хранении? Я знаю только практику по таблице на модуль (для сложных, например форума, соответственно 2 и более).

Перекушу и опишу %)

-~{}~ 17.11.04 21:18:

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

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

Был создан класс для работы с дополнительными полями. В таблице создавалось новое поле текстового типа, дополнительные поля сохранялись в ассоциативном массиве, кодировались и там сохранялись. При передаче хеша полей и их значений в метод добавления данных в БД, дополнительные поля снабжались специальным префиксом, что позволяло отличить их от обычных полей. При извлечении данных из таблицы, специальный метод декодировал структуру и с дополнительными полями в коде или шаблонах можно было работать так, как будто это обычное поле таблицы. В SQL запросах, конечно, такое не прокатит, но все равно технология оказалась очень удобной в использовании. Для того, чтоб добавить новое поле мне было достаточно прописать его имя в шаблоне со специальным префиксом. А для себя я не делаю даже этого, и просто прописываю дополнительные поля и их значения в обычной текстарии %)

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

 

[antiportal]

Перекушу и опишу %)

Приятного аппетита =)

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

У той CMS, о которой я говорил раньше, возможность задавать необходимые поля -- основная фишка. Таблицы модулей сильно(!) отличаются служебными полями, а остальные поля общие -- пронумерованные TEXT со спец. префиксом. "Карта" (name, textarea/text/..., etc) этих полей задается через подключаемый ini.
Не знаю, почему не стали использовать сериализацию.

я могу одним запросом вывести не только "новостей по теме" [...]

Вот это пока единственное, что приходит в голову =)

 

[2NetFly]

У той CMS, о которой я говорил раньше, возможность задавать необходимые поля -- основная фишка. Таблицы модулей сильно(!) отличаются служебными полями, а остальные поля общие -- пронумерованные TEXT со спец. префиксом. "Карта" (name, textarea/text/..., etc) этих полей задается через подключаемый ini.
Не знаю, почему не стали использовать сериализацию.

А можно, если не секрет, немного подробнее по этому аспекту, с примером? Хотя бы в приват =)

Вот это пока единственное, что приходит в голову =)

Еще вспомнил. Я отказался от использования в шаблонах сокращенных имен полей (использую document_type, а не type) в виду того, что постоянно сталкивался с неоднозначности при выборке данных из нескольких таблиц. Кстати говоря, у меня имя каждого поля уникально в пределах базы – очень удобно. Так вот, использование одной таблицы позволяет проще переделывать шаблоны, или даже использовать один и тот же шаблон для разных типов документов.

 

[antiportal]

А можно, если не секрет, немного подробнее по этому аспекту, с примером?

Думаю, это может заинтересовать и паблик.

Все на столько просто, что даже стыдно =) Допустим есть простейшая таблица для обыкновенного текстового типа контента:

| id | field_1 | field_2 | field_3 | .... | field_n |

Количество полей определяется сложностью проекта, но в большинстве случаев хватает 10-15. Тем более, что вставить пару колонок -- не проблема.

Администратор решает, какие поля ввода он хочет использовать -- на какие логические куски разбить документ:
1. Заголовок [title] (text)
2. Ключевые слова [keywords] (text)
3. Содержание [content] (textarea)
4. Рейтинг [rating] (select)
Все эти поля создаются в спец разделе админ-панели, получая уникальное имя (переменной) в рамках этого набора полей. Для списка задаются элементы, например: 1, 2, 3, 4, 5 -- оценки рейтинга. Настройки этого набора полей сохраняются в INI файл с использованием секций как идентификаторов полей:

[1]
name = 'title'
type = 'text'
label = 'Заголовок'
sort = 0
...
[3]
name = 'content'
type = 'textarea'
label= 'Содержание'
sort = 2
...

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

 

[2NetFly]

Этот момент уяснил.

Очень хотелось бы увидеть описание постоянно упоминаемой системы %) Что такое "дерево системы", что представляют собой элементы этого дерева и т.д. Общие принципы, преимущества и основные возможности. Если это доступная (не важно, бесплатная или коммерческая) разработка, был бы благодарен за ссылку либо полную документацию.

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

 

[antiportal]

Система, о которой я говорю, была спроектирована и реализована моим другом при моей активной поддержке ;-). Сейчас он ее дорабатывает для удобства использования и пишет какие-то модули. Релиз системы пока не планируется и ни сайта, ни документации нет. Распространяться она будет платно, но есть версия "мини" для бесплатного распространения.

Весь контент в системе представлен в виде дерева материалов, что является стандартным решением. Дифференциации на "файлы" и "каталоги" нет: любой материал может иметь потомков.
Каждому материалу присваивается модуль, набор полей и шаблон (с учетом наследования).
В дерево не включаются атомарные элементы контента, наличие которых зависит от модуля. Например, у блога такими элементами являются записи, у форума -- топики.
Материалы могут быть рекурсивно включены друг в друга. Функция подключения имеет ряд удобных параметров: указание шаблона, который нужно использовать при включении материала, вкл/откл кэширования для подключаемого элемента.
Например, если мы подключаем меню навигации в страницу новостей, то для него отдельно можно включить кэширование.
Также система обладает рядом стандартных функций: nix-подобная система прав, красивые URLы, WYSIWYG, загрузка изображений с ресайзом и т.д.

 

[2NetFly]

"Дерево материалов" встречалось мне во время обзора коммерческих cms, например в eZ-publish CMS (http://ez.no). Но я смог оценить его только с точки зрения пользователя, а не программиста.

Я на протяжении долгого времени изобретал велосипед и учился исключительно на собственных ошибках. Сейчас решил исправиться (лучше поздно, чем никогда) и изучить и позаимствовать лучшее из того, что создано в сфере CMF / CMS. Выше было сказано, что дерево материалов является стандартным решением. Где можно прочитать об этой технологии и преимуществах ее использования в CMF т.е. при программировании? Может есть какая-нибудь хорошо продокументированная готовая система?

 

[antiportal]

2NetFly

Может есть какая-нибудь хорошо продокументированная готовая система?

Хм.. ну есть Typo3 и та же eZp, а вообще рекомендую CM Bible, CM Design и философию CMS. Это 3 основных творения на тему.

 

[2NetFly]

Последние две уже читал. А вот CM Bible на 750 страниц – это серьезно. Вот бы кто на русский перевел..