Технологические аспекты выбора CMS

Маркетинг10 Создание сайтов3 Контекстная реклама5 SEO4 Комплекс услуг2 Дизайн6 Программирование1 SMM1 Digital2 Использование сервиса1 Мобильная разработка1 Юзабилити2 Брендинг3 Менеджмент2 Интернет-маркетинг1 Интранет

CMSСтатья

1С-БитриксNetCatUMI.CMS

Доклад для Сайт-2009

ИК

Илья "Коля Дубр" Мясин

24 июня 2009

1 722

25 июня Илья Мясин, ведущий программист компании J-Vista и зам. главного редактора CMS Magazine, выступил с докладом на конференции Сайт-2009 в секции "Инструментарий веб-студии". Предлагаем вашему вниманию полный текст доклада, включенный в сборник материалов конференции, и презентацию, продемонстрированную во время выступления. Обратите внимание: презентация иллюстрирует "устную" версию доклада, которая (из-за регламента) получилась значительно короче "письменной", представленной ниже.

Презентация к докладу на конференции "Сайт-2009"

1. Введение

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

2. Общие критерии выбора CMS

Выбор той или иной CMS влияет на работу многих сотрудников и подразделений веб-студии.

Отдел продаж должен в понятной для клиента форме описать преимущества конкретного решения. Кроме того, известность брэнда производителя CMS может сильно повлиять на решение заказчика воспользоваться услугой внедрения продукта.
Системный администратор должен поддерживать работоспособность необходимого для функционирования системы ПО, следить за нагрузками, устанавливать обновления.
Контент-менеджер работает с CMS постоянно, для него важны удобство и понятность интерфейса, скорость работы и другие эргономические характеристики.
Дизайнер должен ограничивать полет творческой мысли - хотя большинство систем позволяет внедрить любой дизайн, некоторые дизайнерские решения могут оказаться сложно реализуемыми.
Верстальщик должен определенным образом разделять макет на значимые области, иногда - соблюдать требования по оформлению HTML-кода (например, если система использует XSLT в качестве шаблонизатора). Верстальщик должен уметь работать с технологией, при помощи которой реализована шаблонизация в данной CMS (XSLT, Smarty, PHP, собственный макро-язык).
Программисты используют API системы для реализации новых сервисов и для адаптации существующего функционала под нужды проекта.

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

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

Некоторые из этих характеристик весьма субъективны, некоторые - противоречивы (например, гибкость часто вступает в противоборство с быстродействием). И, конечно, приоритет каждого аспекта во многом определяется устройством бизнеса веб-студии, спецификой разрабатываемых проектов. В итоге следует понимать, что выбор CMS (движок для сайта) - весьма сложный процесс, и технологические особенности систем – лишь один из ряда критериев выбора.

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

Для анализа необходимо привлекать технических специалистов.
Глубокое понимание технических вопросов доступно не всем, поэтому вокруг технологий часто выстраивают «маркетинговые мифы».
Не всегда возможно полагаться на общедоступные оценки (например, отзывы на форумах), поскольку сложно оценить опыт и квалификацию автора удаленно.
Даже если некоторый отзыв о системе содержит объективное описание проблем, следует помнить, что продукты развиваются, и в последней версии системы недостаток может быть устранен.
Изучение устройства системы в процессе разработки реального проекта может обернуться его провалом, хотя практический опыт – самый очевидный способ оценки новой системы.

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

3. Технологические аспекты

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

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

Можно утверждать, что система, предоставляющая разработчику полный и удобный API для решения описанных в докладе проблем, обладает свойствами CMF (Content Management Framework) – каркаса для создания веб-приложений.

Очень важно изучить все перечисленные ниже аспекты до начала внедрения системы на реальных проектах. Для этого можно анализировать:

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

3.1. Модульная архитектура

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

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

3.2. Шаблон отображения, формирование модульной сетки

В современных веб-приложениях принято выделять два независимых слоя: бизнес-логику и формат отображения (View). Такой подход позволяет упростить процесс разработки и поддержки ПО, распределить объем работы между несколькими специалистами.

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

связка XML/XSLT
Smarty и аналоги
собственный макро-язык системы
шаблонизация на "голом PHP"
отсутствие View-слоя как такового

В большинстве систем логику отображения можно разделить на 2 крупных задачи:

отображение результатов работы отдельных модулей
отображение общего шаблона сайта (Layout, "обвязка")

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

в HTML-шаблоне размечаются некоторые активные области, в которых могут отображаться блоки (например, левая колонка, область контента, правая колонка, футер). При этом привязка блоков к таким областям вынесена из шаблона (например, хранится в БД).
HTML-шаблон содержит всю логику отображения блоков («активный шаблон»), т.е. непосредственно в HTML-коде прописаны необходимые условия и вызовы нужных модулей.

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

3.3. Хранение и извлечение древовидных структур

Представление веб-проекта в виде иерархии – широко распространенная абстракция. Поэтому практически все CMS содержат встроенный инструментарий для работы с древовидными структурами. Следует обратить внимание на способ хранения, используемый системой для таких данных, и на API, предоставляемый системой для доступа к ним.

Существующие способы хранения:

adjacency list (списки смежности)
nested sets (вложенные множества)
materialized path (материализованные пути)
хранение дерева вне БД (например, в формате XML или в файловой системе)

Подробное описание этих подходов можно получить, например, здесь: http://phpclub.ru/faq/Tree/

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

3.4. Управление типами данных

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

Существует два наиболее распространенных подхода к решению этой задачи:

при добавлении новых типов происходит изменение структуры таблиц БД, при создании типа данных выполняется запрос CREATE TABLE…, при изменении состава полей – запрос ALTER TABLE…
структура БД остается неизменной, все значения всех полей хранятся в одной большой таблице вида ItemID | FieldID | FieldValue (модель “Entity-Attribute-Value”, EAV).

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

3.5. Интерфейсы для работы с БД

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

Можно выделить 3 группы интерфейсов, связанных с базой данных:

Слой абстракции базы данных (Database Abstraction Layer) – нужен для сокрытия методов работы с конкретной СУБД за общим интерфейсом. Позволяет переходить на другую СУБД, не переписывая всего кода приложения (например, сменить MySQL на Postgres). Как правило, данный интерфейс включает методы для простого получения результатов запроса в виде объектов, для получения отдельного объекта, отдельного поля и т.д.
Конструктор SQL-запросов – набор методов, позволяющих собирать SQL-запросы «по частям», в зависимости от каких-то условий. Например, реализация паттерна “QueryObject”.
Слой для работы с БД на высоком уровне – подсистема, позволяющая работать с БД в терминах модели данных, используемой в CMS. Это слой, скрывающий уровень запросов и результирующих строк за более высокоуровневой абстракцией объектов, свойств и методов. Такой подход позволяет сократить объем кода и улучшить его читаемость за счет неявного использования информации о типах данных, о связях между ними и о правилах поддержания целостности данных. Однако, как любая абстракция высокого уровня, этот слой может отрицательно влиять на производительность и делать невозможными некоторые «низкоуровневые» операции. Данный слой для своей работы может использовать два предыдущих.

3.6. Система кэширования

В веб-приложениях существует два потенциальных «узких места»: выполнение SQL-запросов и работа шаблонизатора. Распространенный способ получения приемлемой производительности – кэширование данных, т.е. сохранение результата работы приложения в некотором хранилище (это может быть БД, файловая система, оперативная память). Многие системы имеют такую возможность. Следует обратить внимание на следующие свойства подсистемы кэширования:

Где хранится кэш? Хорошей практикой является использование общего интерфейса с возможностью переключения хранилищ.
Что хранится в кэше? Это могут быть произвольные структуры, результат отработки отдельных модулей (в виде готового HTML-кода или промежуточных результатов), страницы целиком.
Как сбрасывается кэш? Удаление кэшированных структур по истечении срока жизни кэша, либо по какому-либо событию.
Насколько прозрачна система кэширования? Должен ли разработчик в своем коде уделять отдельное внимание этой проблеме, или все происходит в автоматическом режиме?

3.7. Мультиязычность, интернационализация

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

непосредственно данные, контент
языковые строки, используемые в шаблоне

Перевод контента может осуществляться выделением независимой ветви сайта, имеющей свою структуру и свой контент (фактически – отдельный сайт). Однако для некоторых задач может потребоваться создание языковых версий отдельных полей объектов.

Выделение языковых данных из шаблонов – вопрос не только интернационализации, но и управляемости проекта в целом. Следует обратить внимание:

как хранятся языковые данные
есть ли возможность поиска по ним
есть ли у пользователя возможность их изменять через интерфейс

3.8. Вспомогательные инструменты

Практически все CMS имеют массив готового кода, пригодного для решения множества типовых задач, но не являющегося частью «ядра» системы («библиотечный код»). Качество такого кода и число решаемых им проблем во многом определяет сложность разработки и поддержки проекта. Вот несколько примеров того, чем может заниматься библиотечный код:

Работа с пользователями: авторизация, определение прав и ролей.
Работа с формами: генерация форм, валидация данных, управление отображением форм, защита от спама.
Работа с почтой: отправка e-mail по шаблону, адресная рассылка.
Работа с файлами: загрузка пользовательских файлов, проверка допустимости размера и типа файла, определение и отображение характеристик файла и т.д.
Средства отладки и профилирования.
Поисковый механизм.
и т.д.

Задачи такого рода могут быть решены при помощи сторонних библиотек (например, из PEAR) или собственными силами разработчика. Однако наличие «родных» средств, протестированных в контексте данной системы и подчиняющихся ее идеологии, будет плюсом.

4. Анализ трех известных CMS

Теперь рассмотрим выделенные ранее аспекты на примере трех популярных систем управления сайтом: 1С-Битрикс, NetCat и UMI.CMS. Продукты выбраны на основе рейтинга CMS Magazine (http://ratings.cmsmagazine.ru/cms_analytics/?box=-1): описаны три наиболее популярных отчуждаемых («коробочных») системы по состоянию на 5.06.2009.

Рейтинг CMS Magazine строится на основе суммарного тИЦ сайтов, созданных на определенной системе и добавленных в каталог проекта. тИЦ (тематический индекс цитируемости) – показатель от Яндекса, определяющий авторитетность сайта на основе ссылок на этот сайт.

Существуют и другие подходы к рейтингованию CMS. Например, компания iTrack в данный момент разрабатывает систему “CMS Tracker”. Система анализирует сайты в доменной зоне RU и, на основе эвристических алгоритмов, пытается определить, на какой системе работает тот или иной проект. Результаты работы CMS Tracker планируются к публикации в конце июня 2009 года.

Summary по каждой системе сопровождается «портретом» системы, составленным из плюсов и минусов, которые отметили посетители CMS Magazine, что позволяет проследить связь между рассмотренными технологическими особенностями системы и субъективными оценками ее пользователей.

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

4.1. 1С-Битрикс

Данная система на сегодняшний день считается лидером российского рынка коммерческих CMS. Актуальная на данных момент версия – 1С-Битрикс 8.0.

4.1.1. Модули и компоненты

Модули в 1С-Битрикс – крупные части приложения, выделенные по логическому признаку и отвечающие за широкий набор функций. Модули предоставляют разработчику API – ряд интерфейсов, используя которые, можно создавать свои расширения. Так, классы и методы служебного назначения, которые можно считать ядром системы (работа с БД, пользователями, событиями и т.д.), относятся к модулю «Главный модуль». Набор поставляемых модулей зависит от редакции системы. Модули включают в свой состав готовые компоненты.

Компоненты – блоки кода, используемые для отображения «атомарных» функциональных единиц сайта. Файлы, принадлежащие компоненту, должны быть организованы в соответствии с требованиями системы. Компонент включает:

бизнес-логику, код, выполняющий нужные действия, формирующий результат работы
шаблон отображения (их может быть несколько)
мета-информацию – описание компонента и принимаемых им параметров
языковые данные

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

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

4.1.2. Шаблоны сайта и шаблоны компонентов

Шаблон сайта (Layout) в Битрикс – PHP-скрипты header.php и footer.php, содержащие вызовы компонентов (например, для вывода в колонках). Пространство между заголовком и футером - «рабочая область», область отображения основного контента документа. CMS позволяет переключать шаблон сайта из панели администратора, а также назначать разным страницам разные шаблоны, используя один из критериев: GET-параметр, положение страницы в структуре сайта, группа пользователей, произвольное выражение (PHP-код).

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

По умолчанию в качестве шаблонизатора используется PHP, однако в документации описан способ подключения XSLT и Smarty в качестве шаблонных движков.

4.1.3. Типизация данных

Все редакции 1С-Битрикс содержат модуль «Информационные блоки», позволяющий организовывать каталоги данных произвольного типа.

Инфоблок – сложная структура, состоящая из:

мета-описания типа данных (название, набор полей)
иерархической структуры – каталога данных
непосредственно данных – элементов инфоблока

О хранении структуры каталога – см. следующий подраздел.

Для расширения набора полей 1С-Битрикс использует модель “Entity-Attribute-Value”, где таблица сущностей (Entity) – b_iblock_element, таблица свойств (Attribute) – b_iblock_property, таблица значений (Value) – b_iblock_element_property. Таблица значений содержит 3 поля для указания значения свойства: VALUE – универсальное текстовое поле, VALUE_NUM – поле для числовых значений, VALUE_ENUM – поле для указателя на элемент классификатора (классификаторы хранятся отдельно).

Битрикс предоставляет визуальный интерфейс для управления информационными блоками – для создания инфоблоков, для добавления и изменения полей. Кроме того, система содержит встроенный механизм для навигации по элементам инфоблока.

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

4.1.4. Структура сайта и каталогов

Одна из особенностей 1С-Битрикс – хранение структуры проекта на основе иерархии директорий файловой системы. При этом навигационное меню хранится отдельно, в специальных файлах. Такой подход, с одной стороны, позволяет гибко управлять видимой пользователю структурой разделов сайта, с другой стороны накладывает ограничения на возможности выборки произвольных данных из разных разделов (поскольку физически данные к разделам не привязаны).

Иерархическая структура информационных блоков хранится при помощи методики Nested Sets («вложенные множества»). «Смещения» задаются в таблице b_iblock_section в полях LEFT_MARGIN и RIGHT_MARGIN. Для каждого инфоблока создается свое дерево, таким образом таблица b_iblock_section содержит множество непересекающихся деревьев.

API модуля «Информационные блоки» содержит ряд методов для работы с иерархией: получение поддерева, получение непосредственных потомков, получение пути до корня, создание, перемещение и удаление узлов.

4.1.5. Summary

(источник: http://bitrix.cmsmagazine.ru/opinions_cms/
)

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

4.2. CMS NetCat

NetCat – одна из старейших систем на российском рынке. Первая публичная версия появилась в 1999 году.

4.2.1. Дерево разделов

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

Разделы хранятся в таблице Subdivision. Способ хранения дерева разделов – Adjacency Lists (списки смежности). Этот способ является наиболее простым, очевидным и понятным, позволяет очень быстро выполнять операции добавления / удаления узлов, однако имеет ограничения при выполнении некоторых запросов на выборку (получение поддерева, получение пути до корня).

Таблица разделов – одна из т.н. «системных таблиц» NetCat. У разработчика существует возможность при необходимости добавить в эту таблицу дополнительные поля через визуальный интерфейс.

4.2.2. Компоненты и модули

Основной инструмент разработчика проектов на системе NetCat – компоненты. Компонент представляет собой сложную конструкцию, в которую входят:

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

Характерная особенность системы NetCat – хранение в базе данных всех перечисленных частей компонента. Редактирование исходных кодов компонентов осуществляется через веб-интерфейс.

Такой подход имеет ряд преимуществ и недостатков. Плюсы:

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

Минусы:

Нельзя использовать удобные функции текстового редактора (автодополнение, подсветка синтаксиса, code folding). В версии 3.5 для редактирования фрагментов кода может использоваться JS-редактор с подсветкой синтаксиса.
Нельзя использовать средства контроля версий.
Фрагменты кода выполняются функцией eval, поэтому необходимо экранировать кавычки (для этого в интерфейсе системы есть специальный инструмент).

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

Для каждого компонента создается таблица, в которой хранятся данные – объекты компонента. Таблица имеет название вида MessageX, где X – идентификатор компонента. Система позволяет создавать «скалярные» поля (строки, числа, даты) и поля-ссылки, связывающие объект с другим объектом или элементом списка-классификатора. Кроме того, для каждого компонента создается ряд служебных полей – ID раздела, к которому привязан объект, ID пользователя, создавшего объект, дата создания и т.д. Такие поля, хотя и имеют одинаковые свойства, разнесены по таблицам компонентов. Таким образом, в системе не существует единого реестра объектов.

Компоненты привязываются к разделам. При этом задаются параметры компонента в разделе, определяется действие компонента по умолчанию, устанавливаются права на действия в компоненте.

В NetCat также существует понятие «модуль» - это более крупный (по сравнению с компонентом) блок кода, реализующий определенный системный функционал (модуль «Кэширование») или публичный сервис («Комментарии»). Модуль может использовать в своей работе компоненты. Исходные коды модулей, в отличие от компонентов, хранятся в файловой системе.

4.2.3. Макеты дизайна, шаблоны

Макеты дизайна, как и компоненты, хранятся в базе данных и редактируются через веб-интерфейс («Разработка» - «Макеты дизайны»). Каждый макет содержит:

верхнюю часть (“header”)
нижнюю часть (“footer”)
шаблон отображения навигационных структур (меню, «хлебных крошек»)
настройки отображения в разделе
пользовательские поля

Деление на header и footer является условным. Фактически header – это часть разметки, которую необходимо отобразить до основного контента, а footer – та, которую нужно показать после контента.

Макет представляет собой PHP-код с включением макропеременных. Код макета выполняется функцией eval, поэтому к макетам относятся те же ограничения, что и к компонентам.

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

В код footer и header включаются вызовы всех дополнительных блоков (например, при помощи функции s_list_class($sub, $cc, $params), отображающей объекты компонента $cc в разделе $sub).

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

4.2.4. Модуль «Кэширование»

В версии NetCat 3.5 появился модуль «Кэширование», повышающий производительность системы. Модуль позволяет кэшировать различные структуры – списки объектов компонентов, результаты выполнения служебных функций, вывод навигации и т.д.

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

4.2.5. Summary

(источник: http://netcat.cmsmagazine.ru/opinions_cms/)

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

4.3. UMI.CMS

UMI.CMS – сравнительно молодая система, появилась на рынке в 2007 году. Благодаря этому разработчики могли с первых версий использовать возможности PHP5.

4.3.1. Модульная система

Модуль в UMI.CMS – логически выделенная совокупность типов данных и программного кода, отвечающего за работу с этими типами в административной и клиентской частях сайта.

Исходный код модуля представляет собой основной PHP-класс, подключаемые классы-расширения (например, для функций администрирования), инструкции для инсталлятора и файлы локализации.

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

4.3.2. Система шаблонизации

UMI.CMS позволяет разработчику один из двух способов шаблонизации: встроенный «tpl-шаблонизатор» - система макроподстановок, и XSLT.

Общий шаблон явным образом привязывается к странице сайта через панель администратора. Модульная сетка формируется шаблоном («активный шаблон») при помощи вызова методов необходимых модулей.

Если используется tpl-шаблон, модули вызываются т.н. «макросами» вида:

%eshop basket('short_basket')%

При использовании XSLT должна применяться конструкция вида:

<xsl:apply-templates select="document('udata://eshop/basket/notemplate')" />

В UMI.CMS реализовано несколько «внутренних протоколов». Каждый протокол определяет формат запроса и возвращает некоторые данные. Таким образом, UMI следует идеологии ReST: система представляется в виде набора сервисов, каждому из которых соответствует URL, зная который, другие части системы или внешние приложения могут получить данные сервиса в формате XML.

Эта концепция дает некоторые преимущества:

Наглядность результата работы сервиса
Возможность тестировать отдельные сервисы
Работа с внешними приложениями (AJAX, Flash)

Однако в целом подход к использованию XSLT в UMI.CMS имеет ряд недостатков:

Необходимость формирования модульной сетки из XSLT заставляет писать код в императивном стиле, который в целом не свойственен данной технологии.
Поскольку набор модулей определяется XSLT-шаблоном, в шаблон предварительно должны быть загружены таблицы преобразования для всех возможных модулей.
XML-документ, содержащий результат работы модуля, имеет довольно сложную структуру, из-за этого приходится строить сложные xPath-запросы.
XSLT имеет ограниченный инструментарий для работы со строками. Поэтому для формирования URL, особенно если они содержат параметры, нужно применять громоздкие конструкции.

4.3.3. Объектная модель UMI.CMS, модуль «Шаблоны данных»

Система хранит все объекты в едином пространстве идентификаторов и использует общий программный интерфейс для доступа к ним. В системе существуют два основных понятия: страница и объект.

Страница – это элемент иерархии сайта, список страниц отображается в модуле «Структура сайта». Для страницы указывается название, строковой код для URL, шаблон отображения, активность, тип страницы. Тип страницы определяется сочетанием модуля и метода, отвечающего за управление данными на этой странице. К странице привязан объект (фактически – страница является «расширенным» объектом).

Объект – сущность, принадлежащая определенному типу данных и имеющая соответствующий набор полей (свойств). Все значения свойств хранятся в общей таблице cms3_object_content, таким образом, UMI использует модель хранения “Entity-Attribute-Value”.

Для управления типами данных предназначен модуль «Шаблоны данных», который входит во все редакции системы линейки “Pro”. Этот модуль предоставляет визуальный интерфейс для создания новых типов и расширения существующих.

В UMI.CMS реализовано наследование типов данных: если некоторый тип B является потомком типа A, объект, принадлежащий типу B, будет иметь все те же поля, что и объект типа A, и ряд собственных полей, определенных типом B.

API системы содержит средства для управления объектами и страницами, и для построения выборок по критериям. Методы, выполняющие выборки, возвращают списки идентификаторов, а полная информация об объектах подгружается в цикле. Это может негативно сказываться на производительности.

4.3.4. Summary

(источник: http://umi.cmsmagazine.ru/opinions_cms/)

UMI.CMS предоставляет удобные и понятные средства для интеграции проектов со стандартным функционалом. С другой стороны, для расширения возможностей системы разработчик должен хорошо понимать ее концептуальные особенности, уметь ориентироваться в обширном API ядра. Использование XSLT-шаблонизатора создает дополнительные требования к квалификации специалиста.

5. Выводы

Когда речь идет о «типовых» проектах, все системы справляются хорошо, и при выборе CMS технологическим аспектам не стоит уделять особого внимания. Если же функционал проекта выходит за рамки стандартного, технологические особенности системы могут ощутимо повлиять на стоимость разработки и поддержки. Таким образом, степень влияния технологических аспектов на выбор CMS должна определяться типом проектов, которым отдает предпочтение веб-студия, компетенцией и опытом сотрудников.

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

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

Илья Мясин,

Компания J-Vista, ведущий программист,

CMS Magazine, заместитель главного редактора.