Платформо-независимый динамический сайт – миф или реальность
Может ли быть веб-сайт независим от платформы? Конечно, если он представлен в статическом 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). Это не есть руководство к действию, но почва для размышлений. Быть может, эта концепция подтолкнет вас к вашему собственному универсальному и практичному решению.
Рекомендуем почитать
