XML Sapiens как универсальная концепция сайтостроения в разрезе XML/PHP

IV международная конференция

«Современные технологии эффективной разработки

веб-приложений с использованием PHP»

12-13 мая 2005 года, г. Киев

Тезисы

1. Почему в веб-разработках неприменимы модели Windows Forms, Win32 API, MFC?

1.1 Расчищаем путь от ТЗ к готовому проекту;

1.2 Подходы к описанию пользовательских интерфейсов UIML, XAML, XUL и Flex;

1.3 Инструментарий разработчика PHP GTK и SMARTY;

1.4 Разделение данных и представления в W3C XSL;

1.5 Комплексное решение для динамических сайтов XML Sapiens.

2. Динамический сайт в объектах

2.1 Управление пользовательскими интерфейсами сайтов в популярных open source проектахCMS;

2.2 Задачи веб-разработчика по управлению объектами сайта;

2.3 Экспресс-экскурс в теорию динамического сайта.

3. Разделяем функциональность, данные и представление по «рецепту» XML Sapiens

3.1 «Три кита» в структуре документа динамического сайта;

3.2 Конструирование пользовательских интерфейсов с помощью контейнеров динамических данных;

3.3 Синтаксис языка описания контейнеров динамических данных.

4. Переносимость динамических сайтов

4.1 Платформы доставки контента и семантический веб;

4.2 Прореха модели XSL;

4.3 Разделение сценариев пользовательских интерфейсов и кода представления.

5. Как XML Sapiens практически реализуется в PHP

5.1 Процессор XML Sapiens собственными руками;

5.2 Алгоритм процессора XML Sapiens.

6. Итоги


Почему в веб-разработках не применимы модели Windows Forms, Win32 API, MFC?

Любой веб-проект начинается с технического задания (ТЗ). Что должно содержать ТЗ? Открываем «библию проект-менеджера» («Управления проектом по созданию интернет-сайта», Альпина паблишер) и находим, что, кроме прочего, ТЗ устанавливает принципы взаимодействия программных модулей, принципы «человеко-машинного диалога», описывает задачи функциональных элементов. Т. е. ТЗ описывает пользовательские интерфейсы сайта. Неудивительно, что проект-менеджеры «спят и видят», как новый проект автоматически собирается на основе их UML-схем. Бизнес-аналитики негодуют: «Мы дали вам логику интерфейсов, почему же на их сборку уходит столько времени?». В Windows, все формы GUI уже «отрисованы» и для создания нового интерфейса достаточно лишь инициализировать класс. Net Frame Work Class Library или же вызвать функцию Win32 API. Каждый новый веб-проект требует уникальных информационной архитектуры и графического дизайна. Соответственно, следует каждый раз создавать все интерфейсы заново. Или все же, как говорят в Microsoft, однажды написанное приложение мы можем развертывать многократно (build-once, deploy n-times)?

НЕ нашли? Не то? Что вы ищете?

Для того чтобы выделить в приложении абстрактный слой интерфейса и управлять им самостоятельно, логично воспользоваться языком разметки UIML (www. uiml. org). В результате мы получили бы четкое дерево структуры пользовательского интерфейса приложения с динамической базой контента элементов и определенной моделью событий.

Для воссоздания многофункциональных интерфейсов можно было бы воспользоваться комплектом XAML + .Net языки для платформы Longhorn и XUL + Java-script/Python/C++ для приложений Gecko-базированных браузеров. По части эффектных интерфейсов по-прежнему вне конкуренции решения от Macromedia. Ныне речь о Flex и обогащенных приложениях (Rich Internet Applications). Впрочем, программисты PHP могут воспользоваться богатым инструментарием GTK (http://gtk. ) для рендеринга GUI-приложений, но это будут уже не совсем веб-приложения.

Очевидно, что библиотека готовых компонентов для реализации сложных форм пользовательского интерфейса (интерактивные деревья, управляемые таблицы, drag&drop и т. д.) существенно сократило бы время разработки проектов. Схематика декларации UIML повысила бы качество сложных веб-интерфейсов. Однако еще до этапа формирования пользовательского интерфейса имеется серьезная и актуальная задача. Веб-документ, помимо интерфейсных форм, содержит также контент и его оформление.

PHP располагает таким зам6ечательным инструментом как SMARTY (http://smarty. ), что позволяет программистам эффективно разделять программный код приложения и его оформление. Но наиболее концептуальных подход предлагает стандарт W3C XSL – компиляция «чистых» данных в XML и их оформления «на лету».

Изображение 1. Данные, представление, пользовательский интерфейс

Данные в формате XML и графический дизайн в формате XSLT поступают на преобразователь XSL. Последний возвращает пользователю документ, готовый к просмотру.

Казалось бы вот и решение. Однако XSL разрабатывался как язык декларации оформления документов, но не разметки пользовательских интерфейсов. Т. е. для полноценного разделения данных, их оформления и форм пользовательских интерфейсов требуется дополнительная технология. XAML, XUL и MXML (Flex) хоть и прямо не отвергают XSL, но по большей части ориентированны на самостоятельный рендеринг приложений.

Пример 1. XSLT описание пользовательского интерфейса простейшего навигационного меню

<xsl:template name="menu">

<xsl:for-each select="child::*">

<div>

<xsl:if test="not(./@state='selected')">

<a class="active" >

<xsl:attribute name="href">

<xsl:value-of select="./variable"/>

</xsl:attribute>

<xsl:value-of select="./label"/>

</a>

</xsl:if>

<xsl:if test="./@state='selected'">

<a class="inactive" >

<xsl:attribute name="href">

<xsl:value-of select="./variable"/>

</xsl:attribute>

<xsl:value-of select="./label"/>

</a> </xsl:if>

</div>

</xsl:for-each>

</xsl:template>

UIML, напротив, полагается на XSL. Однако UIML представляет собой общий подход к описанию пользовательских интерфейсов, и необязательно веб-приложений. И что касается веб-приложений, он будет не всегда эффективен.

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

Методика разделения данных, их оформления и форм пользовательских интерфейсов в CMS детально разобрана в спецификации XML Sapiens. И далее я предлагаю ознакомиться с этой концепцией.

Динамический сайт в объектах

Как реализуется интеграция пользовательских интерфейсов в открытых популярных проектах CMS XOOPS2, TYPO3, Mambo? Там применяется либо собственные конструкции PHP в HTML, либо шаблонизация на базе SMARTY. А к чему стремимся мы?

    Унифицированная концепция; Независимость от платформы; Независимость от форматов представления данных; Простота описания логики интерфейсов.

Как этого достичь? Давайте пробежимся по теории динамических сайтов. Итак, информационное пространство представляет собой множество сайтов и их языковых версий. Каждый сайт является множеством разрозненных документов, где документ – это веб-ресурс с уникальным интернет-адресом. Документ определяет данные и их представление. Структура информационного пространства определяет отношение сайтов между собой. Структура сайта определяет отношение документов между собой. Структура документа определяет наличие, специфику и расположение данных в коде представления.

Задача разработчика организовать:

    Управление структурой информационного пространства, сайта; Управление структурой документа; Управление данными; Управление представлением; Управление функциональностью пользовательских интерфейсов.

Разделяем функциональность, данные и представление по «рецепту» XML Sapiens

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

    Редактируемые в административном режиме фрагменты содержания, относящиеся к данному документу; Статический код, общий для группы документов; Динамический код, формируемый на основе сценария.

Изображение 2. Объекты динамического сайта

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

Контейнеры запросов (QC) – подразумевают:

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

Контейнеры статических данных (SDC) – представляют собой код, общий для группы документов.

Контейнеры динамических данных (DDC) – отображают код, в зависимости от состояния среды (действий пользователя, внешних факторов и т. д.), согласно определенному сценарию. Эти контейнеры, по сути, и есть основа интерфейсов динамических сайтов с позиции XML Sapiens. Как выглядят DDC?

Пример 2. DDC пользовательского интерфейса навигационного меню

<sapi:for-each select="get_tree()" name="enum">

<sapi:choose>

<sapi:when exp="eq(this. this. currentpage. value,1)">

<sapi:code>

<a class="active" sapi:href="this. this. HREF. value"><sapi:apply name="this. this. TITLE. value" /></a><br />

</sapi:code>

</sapi:when>

<sapi:when exp="neq(this. this. currentpage. value,1)">

<sapi:code>

<a class="inactive" sapi:href="this. this. HREF. value"><sapi:apply name="this. this. TITLE. value" /></a><br />

</sapi:code>

</sapi:when>

</sapi:choose>

</sapi:for-each>

Изображение 3. UML DDC пользовательского интерфейса навигационного меню

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

Переносимость динамических сайтов

Жесткая зависимость документов динамических сайтов от его движка противоречит принципам семантического веба (W3C RDF, http://www. w3.org/2001/sw/).

Если мы возьмем типовой движок динамического сайта, то, скорее всего, мы сможем заставить его формировать XML-документы с данными. Если мы возьмем движок, основанный на XSL, то мы будем располагать и данными, и их представлением, независимыми от платформы. XSL позволяет создавать сценарии для динамически формируемых интерфейсов. Однако в XSL алгоритм интерфейса не отделен от кода представления. Может ли XML Sapiens отделить сценарий интерфейса и его представление?

В настоящее время на SourceForge открыт проект процессора сценариев XML Sapiens (http://sapiprocessor. ). Классическое разделение данных и представления подразумевает XML-документ с данными, ссылающийся на XSLT-документ с оформлением. Было бы логично добавить в него ссылку на документ с описанием интерфейсов. Процессор сценариев XML Sapiens, в случае обнаружения подобной ссылки или ссылок на документ со сценариями пользовательских интерфейсов в формате XML Sapiens, анализирует его сценарии и на их основе расширяет документ с данными. После этого обычным образом происходит XSLT-преобразование документа.

Пример 3. Исходный файл данных для процессора сценариев XML Sapiens

<?xml version="1.0" encoding="UTF-8"?>

<?xml-stylesheet type='text/xsl' href='template. xsl'?>

<?xml-sapi type='text/xml' href='interface. sapi'?>

<content xmlns:sapi="http://www. xmlsapiens. org/spec/sapi. dtd" xmlns:xlink="http://www. w3.org/1999/xlink">

<data1>data1</data1>

<data2>data2</data2>

<menu><sapi:apply name="ddc. menu. value" /></menu>

<title><sapi:apply name="qc. title. value"></title>

<publication><sapi:apply name="qc. publication. value"></publication>

</content>

Пример 4. Сценарий XML Sapiens в файле interface. sapi

<?xml version="1.0" encoding="UTF-8"?>

<sapi version="1.0" xmlns:sapi="http://www. xmlsapiens. org/spec/sapi. dtd">

<sapi:ddc name="menu">

<sapi:choose>

<sapi:when exp="TRUE">

<sapi:for-each select="get_tree()">

<sapi:choose>

<sapi:when exp="TRUE">

<sapi:code>

<row sapi:id="this. this. id. value" sapi:activity="this. this. currentpage. value">

<link><sapi:apply name="this. this. href. value" /></link>

<item><sapi:apply name="this. this. title. value" /></item>

</row>

</sapi:code>

</sapi:when>

</sapi:choose>

</sapi:for-each>

</sapi:when>

</sapi:choose>

</sapi:ddc>

</sapi>

Пример 5. Сформированный XML

<?xml version="1.0" encoding="UTF-8"?>

<?xml-stylesheet type='text/xsl' href='template. xsl'?>

<content xmlns:sapi="http://www. xmlsapiens. org/spec/sapi. dtd" xmlns:xlink="http://www. w3.org/1999/xlink">

<data1>data1</data1>

<data2>data2</data2>

<menu>

<row id="01" activity="1">

<link>/intro/</link>

<item>Introduction</item>

</row>

<row id="02" activity="0">

<link>/chapter1/</link>

<item>Chapter 1</item>

</row>

<row id="03" activity="0">

<link>/chapter2/</link>

<item>Chapter 2</item>

</row>

</menu>

<title><![CDATA[Introduction]]></title>

<publication><![CDATA[<p>Content</p>]]></publication>

</content>

Изображение 4. Схема формирования отображаемого документа

Как XML Sapiens практически реализуется в PHP

Сам собой возникает закономерный вопрос: «Как на практике использовать технологию XML Sapiens в собственных проектах?». Потребуется ли для рекомпиляция сервера или же специализированный браузер? На самом деле, для использования концепции XML Sapiens в проекте потребуется добавить к движку его веб-сайта программный процессор XML Sapiens. Как это сделать?

Изображение 5. Модель процессора XML Sapiens

Как вы можете видеть, алгоритм процессора XML Sapiens достаточно прост. На вход программы подается шаблон формируемого документа. Программа перебирает все вхождения указателей XML Sapiens в шаблоне и подставляет на их место код возврата, соответствующего им объекта в файле сценариев XML Sapiens. В PHP подобный алгоритм реализуется особенно легко, благодаря регулярным выражениям PRCE. На выходе программы мы получаем готовый к просмотру документ.

Парадигма MVC для CMS на базе XML Sapiens

Общую модель CMS, базированной на XML Sapiens, можно представить следующим образом.

Изображение 6. Парадигма MVC для CMS на базе XML Sapiens

Запрос из браузера поступает на программный контроллер CMS, который в свою очередь отражает его системной среде окружения. Теперь этот запрос определяет поведение форм пользовательского интерфейса (DDC/QC) при компиляции документов процессором XML Sapiens. Сформированный документ направляется в браузер.

Итоги

·  XML Sapiens содержит интуитивно понятную модель описания пользовательских интерфейсов сайтов;

·  XML Sapiens определяет инфраструктуру динамического сайта, наиболее близкую CMS;

·  XML Sapiens разделяет логику пользовательских интерфейсов сайтов, данные и их представление;

·  XML Sapiens не противоречит принципам семантического веба;

·  XML Sapiens легко реализуется программно.

Выводы

XML Sapiens – открытый проект, созданный веб-разработчиками для веб-разработчиков. Проект несет в себе концепцию сайтостроения, удобную для применения в CMS. Проект динамично развивается и каждый из вас свободно может принять в нем участие.

Ссылки по теме:

·  Адрес сайта проекта: http://xmlsapiens. org

·  Публичная библиотека интерфейсных решений: http://xmlsapiens. org/lib/

·  Англоязычный форум: http://xmlsapiens. org/board/

·  Дискуссионный лист: http://*****/index. php? showforum=29

·  Список рассылки: http://groups. /group/xmlsapiens/

·  Открытый проект CMS на базе XML Sapiens: http://sapid. /

·  Процессор сценариев XML Sapiens: http://sapiprocessor. /

Автор:

Дмитрий Шейко (www. ), ведущий программист Red Graphic Systems (www. )

Краткая информация об авторе:

Занят разработкой программного обеспечения с 1987 года. Начиная с 1998 года опубликовано более 50 авторских технических статей в специализированных изданиях. С 2001 года разрабатывает архитектурные решения и инструментарные средства для управления содержанием. За прошедшее время спроектировал ряд успешных коммерческих продуктов, включая систему электронных публикаций MyPRESS, систему управления информационным пространством MySITE (www. ), среду разработки веб-приложений Site Sapiens (www. *****). Является автором спецификации универсального языка для разработчиков CMS XML Sapiens (www. xmlsapiens. org).