Платформа независимый динамический сайт – миф или реальность?

Может ли быть веб-сайт независим от платформы? Конечно, если он представлен в статическом HTML. А что насчет динамического сайта? Интерактивный сайт может быть представлен в Macromedia Flash. Отчасти интерактивный и не совсем сайт - в PDF-формате. А вот динамический сайт потребует программного интерфейса на стороне сервера, которое в свою очередь потребует серверные приложения. Итого, для создания автономной копии сайта потребуется создавать веб-сервер, и воссоздавать на нем программную среду, аналогичную среде исходного сайта. Неужели нет альтернатив? Давайте взглянем на то, что мы сами можем сделать для переносимости наши проектов.

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

Оформление

Оформление сайта может включать шаблон, задающий структуру документа и информацию о графическом дизайне. Первое подразумевает каркас с указателями на данные, второе (X)HTML+CSS или XSLT или другой формат представления. В любом случае, основная информация об оформлении уже представлена в формате либо XML, либо в смежном формате.

Данные

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

Пример 1. XML контента

<data>

<row ip="127.0.0.1" date_create="2005-01-05 15:22:01">

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

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

</row>

</data>

В данном примере предоставлены элементы содержания doctitle и doccontent. Как видно, они являются потомками элемента ROW. Если документ включает в себя несколько страниц, то благодаря этому элементу вы сможете без труда разделить их данные.

Структура

Структура определяет то, как документы сайта связаны между собой. Чаще всего структура представляется в виде иерархического дерева. Давайте и мы будем из этого исходить при формировании XML. А как же граф? Как же быть с многоаспектными отношениями объектов? Информацию о внеиерархических связях объектов мы также включим в XML. Рассмотрим пример:

Пример 2. XML структуры

<tree>

<treeitem var="root" id="id_0" visible="true" owner="root" group="wheel" permissions="770">

<title>The Website</title>

<treeitem var="en" id="id_1" visible="false" owner="root" group="wheel" permissions="777">

<title>English</title>

<link type="arc" role="languages" from="id_5" to="id_5" />

<template>main.tpl</template>

<treeitem var="virtual" id="id_4" visible="false" owner="root" group="wheel" permissions="770">

<title>Year mask</title>

<template>main.tpl</template>

</treeitem>

</treeitem>

<treeitem var="ru" id="id_5" visible="false" owner="root" group="wheel" permissions="777">

<title>Russian</title>

<link type="arc" role="languages" from="id_1" to="id_1" />

<template>main_ru.tpl</template>

</treeitem>

</treeitem>

</tree>

Выше приведена иерархическая структура, где объекты структуры сайта представлены элементами TREEITEM. Этот элемент содержит следующие атрибуты:

Var – определяет составную часть URI для текущего документа

Id – идентификатор документа для DOM

Visible – состояние документа для в интерактивном дереве

Owner – владелец документа

Group – пользовательская группа документа

Permissions – права на доступ к документу

Как вы наверняка догадались исходя из примера, принцип назначения прав документам унаследован от UNIX. 3 цифры в атрибуте Permissions указывают на то, могут ли владелец/группа/все прочие изменять/ удалять/ просматривать документ.

Элемент TITLE содержит название документа. В названии допускаются кавычки и более одной строки содержания. Элемент TEMPLATE содержит имя файла с шаблоном оформления.

А теперь самое интересное. Элемент LINK описывает внеиерархические связи документов. Скажем, на нашем сайте представлены документы о книгах. Они рассортированы по тематике содержания. Однако нам необходимо разделить книги в мягкой обложке и книги в твердом переплете. Мы размещаем в описании документа книги либо <link role="hard_cover">, либо <link role="soft_cover">. Если нам необходимо «зеркало» определенного документа в новой позиции структуры мы используем <link type="mirror" id="id_of_document"> или <link type="datamirror" id="id_of_document">, когда «зеркалируются» лишь данные, но не шаблон. Допустим, нам нужна непосредственная связь для нескольких документов – мы вносим <link type="location" role="see_also" from="id_of_document">. Т.е. текущий документ является потомком для заданного в атрибуте FROM, по признаку «see_also». И, наконец, знаменитая «дуга обхода». В приведенном выше примере предполагается, что разделы языковых версий сайта связанны между собой дугой обхода. Запись <link type="arc" role="languages" from="id_5" to="id_5" /> указывает то, куда от текущего документа двигаться по направлениям «вперед» и «назад».

Неправда ли, похоже на xLink от W3C? Возникает вопрос: «Зачем потребовалось что-то придумывать, когда имеется утвержденный W3C стандарт?». Видите ли, если представлять структуру сайта списком xLink и адресовать документы взаимонезависимыми URI, то в дальнейшем практически управлять подобной структурой будет затруднительно. Сама по себе банальная задача удалить/добавить/перенести/скопировать раздел структуры может стать огромным камнем преткновения.

Интерфейсы

Итак, данные, оформление и структуру мы уже описали в XML. Можем ли мы аналогичным образом описать в XML логику интерфейсов? То как это можно сделать детально описано в спецификации XML Sapiens (http://www.xmlsapiens.org), в том числе и на русском языке, а общедоступная реализация расположена по адресу http://sapid.sf.net

В данной статье я представил лишь вариант транспортного формата для динамических сайтов. Кстати говоря, вариант практически опробован на проекте SAPID (http://sapid.sf.net). Это не есть руководство к действию, но почва для размышлений. Быть может, эта концепция подтолкнет вас к вашему собственному универсальному и практичному решению.