Теоретические основы CMS: платформа и панель управления.
CMS matrix и отечественный CMSlist предлагают список доступных продуктов, из которых на нынешнее время наиболее популярные западные — Drupal, Joomla; Российские — Битрикс, UMI CMS, NetCat. Однако чем универсальней система, тем более она громоздка, заторможена необходимостью в поддержке старых версий и поэтому программисты пишут свои системы. Поэтому я привожу общие принципы.
Framework
Всё начинается с платформы, т.е. расширение языка функциями и объектами, использование которых значительно облегчит дальнейшую систему. На данный момент основные законодатели мод на PHP:
На других менее популярных языках фреймворки соответсвенно Python - Plone, Java - Spring, Struts
Все они по разному запускают внутренние процессы, по-разному хранят данные и файлы и как правило отвечают за
- Разделение логики исполняемого кода по MVC
- Кэширование (объектов и темплейтов)
- ЧПУ (Умные URL)
- Кодировку текста (UTF8) и тип данных (MIME)
- Упрощённый/абстрагированный доступ к БД (PEAR DB2, ADO DB)
- Адрессацию и запуск более высоких уровней приложения
Панель управления
После выбора платформы, разработчики и архитекты по разному решают проблему управления содержанием. Есть два основных пути:
- Наглядное управление. Меню, статьи и всё редактируется в том же дизайне что и весь сайт. Элементы управления при этом видны привелигированным пользователям. Плюс такой реализации в лёгкости понимания - клиент видит статью, нажимает иконку и тут же редактирует содержимое.
- Админпанель. Параллельно с публичной частью создаётся панель управления, разделяемая на модули. Модульность наглядно демонстрирует расширяемость, центральная система авторизации гарантирует меньшую степень риска в доступе к закрытым данным и более лёгкую работу программисту.
Иерархичная структура меню создаётся либо в уникальном табличном экземпляре, либо (что реже) в отдельных таблицах. Связка ID-parentID для уровней с большой глубиной и большой посещаемостью не годится и поэтому реализуется кэширование либо параллельной таблицей, либо в темплейтах. В более разных допотопных CMS, меню можно встретить в виде массивов прописанных сразу в php-файлах, в таком случае можно ожидать что языки и переводы сделаны так же.
Модульность
Фактическое содержание той или иной страницы зависит от модуля который реализует функциональный уровень (бизнес-логику). Оценить сложность системы можно очень просто — может ли клиент на одной странице создать две работающих контактных формы (или две статьи)? Обычно ответ - нет, поскольку со страницей связан как правило только один модуль (скажем "текст", "опрос", "контакт", "ЧаВо").
В то же время дизайнеры любят нагрузить темплейт дополнительными модулями (мини список новостей, опрос). В таком случае проблема нескольких блоков на странице решается
- Выбираемыми темплейтами (под каждую страницу) и smarty-функциями (вызываемые напрямую из темплейта) - не самое лучшее решение из-за смешивания представления и трудности обратного поиска
- Связкой 1:n между страницей и модулями. Усложняет архитектуру, внося внутреннюю адрессацию под модули
Модули как правило имеют свои ресурсы (css,js,img) и естественно возникает вопрос - где и как их хранить. Следует ли использовать разделение по типу ресурса в корне сайта, а потом делить по названиям модулей, либо наоборот - сначала названия модулей, а потом типы ресурсов. Первый вариант хорош что сразу ясно где какие типы и есть возможность масштабирования, тогда как второй вариант предоставляет лучшую модульность при переносе с проекта на проект как кирпичи.
Мелочи
Обычно дерево содержания делается зависимым от языка, т.е. для каждого языка свои деревья. В отдельной статье я писал об этом более подробно.
Пользователи как и группы, роли и права реализуются наряду с системой авторизации, слежения (log=accounting). Особо сложностей в этом нет, самая неясная тема это связывание прав с действиями и объектами. Реализация этого целиком зависит от особенностей той или иной CMS.
Поддержка
Если вы начали активно устанавливать систему как продукт на сайты то неизбежно возникает проблема технической поддержки, версионности и как следствие - ручного или автообновления. В первом случае живые сайты приходится латать самому, делать до этого копию на всякий пожарный. Это может быть небольшой работой при небольшом числе проектов (до 10), но если их 50, и каждое обновление занимает в районе 2 часов, то заставляет задуматься. Во втором случае надо учитывать в архитектуре что некоторые области системы будут общими для всех обновляемых сайтов и будут перезаписаны.
Если у вас хорошее видение архитектуры и достаточно ресурсов (в районе 60 человеко-дней), то можно самому написать систему автообновления где каждый update архив состоит из sql, tpl, языков, custom php, файлов, в ручную закачивается на все ваши системы и обновляет их. В дополнение можно за 15 человеко-дней сделать и центральную авторизацию что-бы не держать на каждом сайте своего пользователя а иметь их на одном сервере (удобно когда есть текучка кадров). Естественно обе системы должны быть максимально защищёнными от несанкционированного доступа.
Автообновление может быть значительно упрощено если все проекты лежат на вашем хостинге, но стоит задуматься нужны ли вам серверные проблемы.
Библиотеки js
Не стоит путать платформы для работы на сервере от платформ для интерфейса. Хотя они и могут вместе быть разработаны, но языки php и js всётаки разные. Для ускорения загрузки страницы в хороших CMS существуют функции кэширования и объединения разрознённых js и css файлов. WYSIWYG-редакторы как правило выбираются из FCKeditor и TinyMCE из-за своей кросс-браузерности.
API и документация
Не стоит забывать о документации. Вы можете написать идеальную CMS, с множеством функций облегчающих жизнь, но без описаний как что можно использовать, без комментариев к функциям или смысла модулей невозможно новому человеку понять что происходит.
Некоторые компании специализируются именно на разработке собственной CMS, перепродавая её использование третьим фирмам и берутся за реализацию только богатых клиентов. Поскольку надеятся на благонадёжность клиентов-разработчиков не приходится, то ядро системы шифруется через Zend Guard или Ion Cube.
http://www.jackslocum.com/blog/
http://www.ajaxian.com/
http://www.crossedconnections.org/w/
http://wiki.agiledev.ru
|
