Речь пойдет о недавно открытом Open Source проекте SAPID CMF. Само по себе название SAPID кому-то может показаться чем-то смутно знакомым. Да, жила-была такая простенькая CMS SAPID, которая позволяла администрировать сайты inline, требовала лишь 1МБ дискового пространства и умудрялась обходиться без СУБД. Однако мало кто помнит, что создавалась эта система с целью продемонстрировать возможности парадигмы XML Sapiens. CMS SAPID благополучно и помпезно встретила свою первую годовщину, а затем 2 года никаких существенных ее новых релизов, как это ни прискорбно, не наблюдалось. Впрочем, последний год на сайте сообщества SAPID время от времени проскакивала информация о работах над новой ветвью проекта SAPID CMF. Вуаля! Вот она — ветка, доступна для загрузки (http://sapidcmf.sourceforge.net) и для «шапочного» знакомства (http://cmfdemo.xmlsapiens.org).
SAPID CMF – это, что-то вроде набора «два в одном», где SAPID – система управления контентом с базовым административным интерфейсом и CMF – конструктор для превращения это интерфейса в собственную кастомизированную систему.
Любая CMS – это с одной стороны движок для веб-приложений, с другой – интерфейс для администрирования этих приложений. Логично было бы предположить, что приложения области доставки (те, что доступны пользователям сайта) и приложения административной панели CMS функционируют на базе одного движка, подчиняются единой логике, используют единый принцип шаблонов. Таким образом, CMS, позволяющая создание внешних веб-приложений, с той же легкостью должна обеспечить создание внутренних административных интерфейсов. Сердце SAPID – процессор XML Sapiens. XML Sapiens — декларативный язык, для описания шаблонов структур данных, оформления и функциональности. С помощью языка можно создавать компоненты для всех трех уровней (данные, оформление, функциональность) и использовать их многократно (reusing), подобно кубикам конструктора, для получения самых различных решений. Процессор XML Sapiens компилирует эти компоненты в готовый пользовательский интерфейс приложения.
Для веб-приложений, в отличие от настольных программ, нет заданного набора элементов управления GTK. Это и достоинство и недостаток. При создании каждого нового приложения или группы приложений разработчики вынуждены создавать новый GTK. Дабы облегчить жизнь разработчикам, GTK административной панели SAPID CMF выполнена на манер Windows. В каждом ее приложении имеются рабочая область, меню, модальные окна, окна сообщений, диалогов, процессов. Доступны компоненты – tree view и list view. Таким образом, мы имеем эдакий «джентльменский набор» для быстрого создания приложений административной панели в едином стиле.
Готовность к развитию
Вы скажете: «Отлично! Я добавлю в административную панель собственные приложения. Через месяц появится новый релиз фреймворка. Я выполню обновление и потеряю всю свою работу». На самом деле SAPID CMF организован так, что при обновлении заменяются лишь базовые компоненты, а дополнительные компоненты, добавленные разработчиком останутся нетронутыми. Возникает вопрос: «Как модифицировать базовые компоненты и защитить код модификации от перезаписи при обновлении?». В SAPID CMF используется событийная модель в стиле аспект-ориентированного программирования. В системе определены различные события. Вы можете добавить собственные обработчики различных событий, модифицирующие среду должным образом. Код модификации будет помещен в папку plugins, которая пропускается при обновлении фреймворка. В терминах АОП для внесения модификаций в базовые компоненты (библиотеки API, контроллеры и т.д.) вы определяете некоторый аспект модификации.
$ModalWindowCustomization = new Aspect();
Задаете для него область прослушивания, скажем все классы и все методы
$pc = $ModalWindowCustomization->pointcut(«call *::*»);
и назначаете определенному событию код модификации
$pc->_event(«ModalWindowSchemasDefined», «customizateModalWindow(\$obj);»);
Как уже говорилось сверхзадача SAPID CMF обеспечить эффективное многократное использование заготовок структур данных, оформления и функциональности при создании веб-приложений. Фреймворк содержит корневую папку VIEWS. В ней имеются папка DEFAULT для шаблонов темы оформления административной панели по умолчанию и папка DELIVERY для шаблонов приложений, созданных на базе фреймворка. Если вы добавите дополнительные темы оформления, здесь появятся соответствующие им папки. Любая из них содержит шаблоны функциональности (папка DDC), наборы полей (папка FIELDSETs), шаблоны запросов содержания (папка QCs) и шаблоны оформления (папка TEMPLATES).
Однажды написав, используем многократно
При создании веб-приложения в сверстанном скетче логической страницы определяются динамические области. К примеру, мы вырезаем блоки меню, блоки списков и т.д. и переносим их код оформления в соответствующие DDC. DDC помимо кода оформления задает также и логику динамического блока. Здесь могут быть использованы условия, перечисления данных у запрошенных приложений CMS, включения, выражения XML Sapiens, а также неограниченная вложенность данных структур. Для описания данной логики используется XML. XML Sapiens позволяет использовать один и то же DDC для формирования различных динамических блоков. При вызове DDC могут быть переданы параметры, которые могут быть рассмотрены в условиях DDC.
<sapi:apply name=«ddc.#submenu.value»>
<sapi:param name=«root»>structure</sapi:param>
</sapi:apply>
Если в коде динамического блока или в коде шаблона логической страницы предполагается форма ввода данных, мы обращаемся к QC. QC определяет каким образом будут отображены или запрошены сообщенные ему данные. Скажем, если мы используем вызов типа <sapi:apply name=«qc.contentblock.value» type=«article» title=«Введите содержание» />, в состоянии администрирования логической страницы мы увидим запрос с редактором WYSIWYG (соответствует типу article) и с заголовком «Введите содержание». В состоянии доставки содержания (просмотра) страницы, нам будет показано содержание контейнера contentblock, введенное по данному запросу при администрировании.
Если набор полей формы запроса данных варьируется динамически (зависит от состояния среды), мы можем использовать вызов набора полей. Например,
<sapi:include href=«fieldset1.xml» parse=«fieldset» state=«admin» />
Данная конструкция вернет набор полей запроса содержания, соответствующий состоянию admin в файле fieldset1.xml.
Какова теория на практике?
Вполне возможно дочитав до этого места, вы подумали: «Все эти нагромождения выглядят как-то страшновато. Интересно, а может ли хоть что-то на этом фреймворке реально заработать?». В дистрибутивном пакете вместе с фреймворком поставляется готовый демонстрационный сайт. Помимо типовых вещей сайт содержит пример формы авторизации/регистрации с использованием AJAX. Форма также включает возможность авторизации по OpenID. На сайте представлен пример рекламного места для баннеров, смешанных типов (GIF/Flash/DHTML/RichMedia). Имеется также пример использования технологии IntelliTXT. Термины, внесенные в тезаурус системы автоматически преобразовывается в текстах страниц сайта в ссылки tooltip (ссылки с двойным подчеркиванием). При наведении курсора мыши на ссылку всплывает окно с подсказкой. Система ведет статистику показов связанных со ссылками окон, так что этот механизм вполне можно использовать для контекстной рекламы.
Демонстрационный сайт содержит пример многоуровневой галереи с возможностью комментирования фотографий. Допустимо голосование, как за фотографии, так и за комментарии. Пример каталога на сайте демонстрирует возможности группировки продуктов по тегам (схожие товары, облако тегов). В общем, есть с чем работать и более того есть некоторый базовый набор решений, которые можно смело использовать в своих проектах.
