 |
|
|||
Технологические аспекты выбора 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, заместитель главного редактора.
Автор: Илья "Коля Дубр" Мясин Комментарии (3) |
|
|
||
|
© 2006-2016 CMS Magazine Правовая информация Статьи партнеров Реклама
CMS Magazine – электронное СМИ. Эл № ФС 77-32705. Статьи партнеров Рейтинг Рунета: рейтинг веб студий, рейтинг seo компаний, рейтинг CMS. 
|
|
 |
||
Потенциальным заказчикам, руководителям, топ-менеджерам, it-директорам и т.д. коммерческим организациям, на заметку.
Помните, что создание сайта, не является конечной целью, это лишь инструмент с которым требуется постоянно работать. Работать с этим инструментом над достижением Ваших высоких целей, будут люди. Работ очень много и они все такие разные, от синхронности этих работ и уровня профессионализма исполнителей будет завесить всё. Поэтому первое, над чем я Вам рекомендую подумать, чтобы потом не сильно жалеть о потерянном времени, кто, что и как будет делать и за что отвечать. Возможно, это будут Ваши сотрудники, возможно сторонние специалисты или профессиональные компании. Выберите сначала ответственных исполнителей, которым Вы готовы доверить будущие своей компании в Интернете, потому что даже самая лучшая и идеальная CMS сама по себе ни на что не способна.
И смотреть все CMS надо именно в работе, попросить показать как будет осуществляться все наиболее востребованные операции, как загружается графика, как редактируются тексты, создаются страницы и т.д.
Если неудобно (или вам кажется,что неудобно) НЕ БЕРИТЕ такую CMS, несмотря ни на какие громкие имена. Берите то, с чем будет удобно и приятно работать.
Любая CMS с доработками под ваш проект уже становится уникальной, поэтому не тешьте себя надежной, что известные CMS сможет легко доработать любой разработчик. Это не так!
когда начинал, всегда было интересно прочитать мнения людей про те CMS, что они используют.
Много шишек набил сам.
По итогам которых решил напистать мой обзор CMS: joomla, drupal, wordpress, livestreet