 |
|
|||
Технологические аспекты выбора CMSУпоминаемые CMS
Дата публикации: 25.06.2009
25 июня Илья Мясин, ведущий программист компании J-Vista и зам. главного редактора CMS Magazine, выступил с докладом на конференции Сайт-2009 в секции "Инструментарий веб-студии". Предлагаем вашему вниманию полный текст доклада, включенный в сборник материалов конференции, и презентацию, продемонстрированную во время выступления. Обратите внимание: презентация иллюстрирует "устную" версию доклада, которая (из-за регламента) получилась значительно короче "письменной", представленной ниже. Презентация к докладу на конференции "Сайт-2009"1. ВведениеМожно без преувеличения сказать, что система управления веб-контентом (CMS) - один из главных инструментов веб-студии. Существуют проекты, для которых использование CMS не является оправданным (например, промо-сайты, не требующие обновления контента, или специализированные сервисы с нестандартным функционалом). Однако большинство студий в повседневной практике работает над проектами, масштаб и задачи которых хорошо ложатся на спектр возможностей современных CMS. Кроме того, производители CMS активно расширяют сферы возможного применения своих продуктов, предлагая готовые модули, инструменты и подходы для решения все новых задач (например, для создания интернет-магазинов, социальных сетей, блогов и других интерактивных проектов).
2. Общие критерии выбора CMSВыбор той или иной CMS влияет на работу многих сотрудников и подразделений веб-студии.
Таким образом, существует множество аспектов работы с CMS, и "технологические" тонкости, интересные программистам и верстальщикам (часто эти роли совмещаются в одном сотруднике) - далеко не единственный фактор, который может влиять на выбор системы. Вот далеко не полный перечень характеристик, определяющих пригодность системы для нужд студии:
Некоторые из этих характеристик весьма субъективны, некоторые - противоречивы (например, гибкость часто вступает в противоборство с быстродействием). И, конечно, приоритет каждого аспекта во многом определяется устройством бизнеса веб-студии, спецификой разрабатываемых проектов. В итоге следует понимать, что выбор CMS (движок для сайта) - весьма сложный процесс, и технологические особенности систем – лишь один из ряда критериев выбора.
Однако технологические аспекты сложнее других поддаются анализу по ряду причин:
В данном докладе я постараюсь помочь слушателям формализовать и упростить задачу анализа технологических особенностей систем управления сайтом.
3. Технологические аспектыЛюбая система управления контентом сталкивается с набором типовых проблем, и ее разработчики должны применить то или иное технологическое решение. Из комплекса таких решений и формируется архитектура приложения, концепция и идеология. В своем докладе я постараюсь перечислить основные, общие для всех систем, проблемы. Разобравшись, как в той или иной CMS решена каждая из перечисленных проблем, можно составить представление, чем является система с точки зрения технологий.
Следует отметить, что, как правило, для каждой проблемы существует несколько концептуальных способов решения, каждый из которых имеет свои преимущества и недостатки. Выделить какой-то один лучший способ не всегда возможно, поскольку качество решения определяется еще и предполагаемой областью применения, и контекстом других архитектурных решений системы, и качеством конкретной реализации.
Можно утверждать, что система, предоставляющая разработчику полный и удобный API для решения описанных в докладе проблем, обладает свойствами CMF (Content Management Framework) – каркаса для создания веб-приложений.
Очень важно изучить все перечисленные ниже аспекты до начала внедрения системы на реальных проектах. Для этого можно анализировать:
3.1. Модульная архитектураБольшинство современных систем строится по модульному принципу, когда функциональные возможности системы объединяются в логические блоки – модули. В разных системах такие элементы могут называться по-разному: компоненты, виджеты, плагины и т.д. Как правило, вместе с системой поставляется набор готовых модулей от производителя, и существует возможность добавлять в систему собственные модули.
Важно обратить внимание, как хранятся модули системы, из каких частей состоят, как устанавливаются, как могут взаимодействовать с ядром системы и с другими модулями, какие возможности по созданию собственных модулей предоставляет система разработчику.
3.2. Шаблон отображения, формирование модульной сеткиВ современных веб-приложениях принято выделять два независимых слоя: бизнес-логику и формат отображения (View). Такой подход позволяет упростить процесс разработки и поддержки ПО, распределить объем работы между несколькими специалистами.
Адаптация программной части под дизайн проекта - практически неизбежный этап работы над сайтом. Поэтому следует особенно внимательно изучить, какие средства шаблонизации предоставляет система. В настоящее время могут использоваться следующие технологии и подходы:
В большинстве систем логику отображения можно разделить на 2 крупных задачи:
Слой формирования модульной сетки должен определить, на каких страницах проекта в каких местах какие модули следует отобразить. Эта задача может быть решена двумя способами:
Для создания общего шаблона и шаблонов отдельных модулей могут использоваться разные технологии, поскольку эти задачи имеют концептуальные различия.
3.3. Хранение и извлечение древовидных структурПредставление веб-проекта в виде иерархии – широко распространенная абстракция. Поэтому практически все CMS содержат встроенный инструментарий для работы с древовидными структурами. Следует обратить внимание на способ хранения, используемый системой для таких данных, и на API, предоставляемый системой для доступа к ним.
Существующие способы хранения:
Подробное описание этих подходов можно получить, например, здесь: http://phpclub.ru/faq/Tree/
Каждый способ имеет свои плюсы и минусы, которые проявляются в зависимости от специфики задач конкретного проекта. Поэтому многие системы используют комбинации и модификации перечисленных подходов.
3.4. Управление типами данныхПри разработке веб-проектов приходится иметь дело с самыми разнообразными данными, и создание системы, имеющей готовый функционал для работы со всеми существующими типами данных, не представляется возможным. Однако, при всем многообразии видов информации, существует всего три базовых действия, применимых к данным любого типа – создание, изменение и удаление. Поэтому большинство современных CMS предоставляют возможность добавлять пользовательские типы данных, которыми затем можно управлять.
Существует два наиболее распространенных подхода к решению этой задачи:
Второй подход, при видимой универсальности и изяществе, имеет определенные недостатки, связанные с выборкой данных по нескольким условиями и группировкой результата.
3.5. Интерфейсы для работы с БДБольшинство современных систем использует для хранения информации реляционные базы данных. Значительная часть кода проекта описывает операции по взаимодействию с БД, и система должна предоставлять разработчику удобные интерфейсы для упрощения этого взаимодействия.
Можно выделить 3 группы интерфейсов, связанных с базой данных:
3.6. Система кэшированияВ веб-приложениях существует два потенциальных «узких места»: выполнение SQL-запросов и работа шаблонизатора. Распространенный способ получения приемлемой производительности – кэширование данных, т.е. сохранение результата работы приложения в некотором хранилище (это может быть БД, файловая система, оперативная память). Многие системы имеют такую возможность. Следует обратить внимание на следующие свойства подсистемы кэширования:
3.7. Мультиязычность, интернационализацияПоддержка нескольких языков – весьма частое требование для современных веб-проектов. Языковая информация, требующая перевода, делится на два основных типа:
Перевод контента может осуществляться выделением независимой ветви сайта, имеющей свою структуру и свой контент (фактически – отдельный сайт). Однако для некоторых задач может потребоваться создание языковых версий отдельных полей объектов.
Выделение языковых данных из шаблонов – вопрос не только интернационализации, но и управляемости проекта в целом. Следует обратить внимание:
3.8. Вспомогательные инструментыПрактически все CMS имеют массив готового кода, пригодного для решения множества типовых задач, но не являющегося частью «ядра» системы («библиотечный код»). Качество такого кода и число решаемых им проблем во многом определяет сложность разработки и поддержки проекта. Вот несколько примеров того, чем может заниматься библиотечный код:
Задачи такого рода могут быть решены при помощи сторонних библиотек (например, из 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 NetCatNetCat – одна из старейших систем на российском рынке. Первая публичная версия появилась в 1999 году.
4.2.1. Дерево разделовДерево разделов в NetCat является центральным элементом, вокруг которого формируется весь функционал сайта.
Разделы хранятся в таблице Subdivision. Способ хранения дерева разделов – Adjacency Lists (списки смежности). Этот способ является наиболее простым, очевидным и понятным, позволяет очень быстро выполнять операции добавления / удаления узлов, однако имеет ограничения при выполнении некоторых запросов на выборку (получение поддерева, получение пути до корня).
Таблица разделов – одна из т.н. «системных таблиц» NetCat. У разработчика существует возможность при необходимости добавить в эту таблицу дополнительные поля через визуальный интерфейс.
4.2.2. Компоненты и модулиОсновной инструмент разработчика проектов на системе NetCat – компоненты. Компонент представляет собой сложную конструкцию, в которую входят:
Характерная особенность системы NetCat – хранение в базе данных всех перечисленных частей компонента. Редактирование исходных кодов компонентов осуществляется через веб-интерфейс.
 Такой подход имеет ряд преимуществ и недостатков. Плюсы:
Минусы:
В следующей версии системы планируется возможность хранения кода, связанного с компонентами, в обычных файлах.
Для каждого компонента создается таблица, в которой хранятся данные – объекты компонента. Таблица имеет название вида MessageX, где X – идентификатор компонента. Система позволяет создавать «скалярные» поля (строки, числа, даты) и поля-ссылки, связывающие объект с другим объектом или элементом списка-классификатора. Кроме того, для каждого компонента создается ряд служебных полей – ID раздела, к которому привязан объект, ID пользователя, создавшего объект, дата создания и т.д. Такие поля, хотя и имеют одинаковые свойства, разнесены по таблицам компонентов. Таким образом, в системе не существует единого реестра объектов.
Компоненты привязываются к разделам. При этом задаются параметры компонента в разделе, определяется действие компонента по умолчанию, устанавливаются права на действия в компоненте.
В NetCat также существует понятие «модуль» - это более крупный (по сравнению с компонентом) блок кода, реализующий определенный системный функционал (модуль «Кэширование») или публичный сервис («Комментарии»). Модуль может использовать в своей работе компоненты. Исходные коды модулей, в отличие от компонентов, хранятся в файловой системе.
4.2.3. Макеты дизайна, шаблоныМакеты дизайна, как и компоненты, хранятся в базе данных и редактируются через веб-интерфейс («Разработка» - «Макеты дизайны»). Каждый макет содержит:
Деление на 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.CMSUMI.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.
Эта концепция дает некоторые преимущества:
Однако в целом подход к использованию XSLT в UMI.CMS имеет ряд недостатков:
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, заместитель главного редактора.
Автор: Илья "Коля Дубр" Мясин |
|
|
||
|
© 2006-2018 CMS Magazine Правовая информация Статьи партнеров Реклама
CMS Magazine – электронное СМИ. Эл № ФС 77-32705. Статьи партнеров Рейтинг Рунета: рейтинг веб студий, рейтинг seo компаний, рейтинг CMS. 
|
|
 |
||
