.:Публикации:. [www.karlson.ru]


Вперед: 2.3 Установка системы Вверх: Глава 2. Информационная система Назад: 2.1 Информационная система WebOS   Содержание

2.2 Интерфейс к интернет-системе WebOs Publishing

При формировании концепции интернет-системы WebOs Publishing автор исходил из той предпосылки, что с системой должны иметь возможность одинаково удобно работать два типа пользователей -- HTML-верстальщики (или дизайнеры) и программисты. Система представляет собой здоровый компромисс между мелкой гранулированностью и отделением дизайна от программной части. Подобный компромисс достигается путем введения четкой модульной структуры, элементов объектно-ориентированного подхода и сериализации структуры для редактирования HTML-кода в привычном для верстальщиков виде. Основные элементы системы:
  • Модуль -- составной элемент структуры системы. Результатом обработки модуля ядром является фрагмент HMTL-кода. Модули бывают статические и динамические. Статический модуль -- модуль, который представляет собой HMTL-код с минимальными вкраплениями разметки системы. Динамический модуль -- функция, написанная на языке Perl. Динамический модуль не может иметь никакой HTML-разметки; весь HTML должен быть вынесен в статические модули.
  • Библиотека модулей -- совокупность статических и динамических модулей, реализующая некоторую функциональность сайта. Динамические модули образуют ОО-класс в терминах языка Perl5.
  • Слот -- некоторая точка внутри модуля, в которую может быть вставлен другой модуль.
  • Вызов -- имя модуля и набор слотов. Вызов может включать имена слотов, которым устанавливаются значения и/или упорядоченные параметры, которые соответствуют слотам, имена которых являются порядковым номером параметра. В HTML-коде слоты бывают именованные и неименованные. Именованный слот просто указывает участок, в который внешний модуль по отношению к текущему может вставить некоторый другой модуль. Именованный слот может содержать вызов -- он будет отработан в том случае, если в слот не будет вставлено никакого модуля. Неименованный слот является простым вызовом.
Система состоит из следующих компонент:
  • Ядро -- программа, динамически (во время HTTP-запроса) преобразующая внутренние структуры системы в HMTL-код.
  • база модулей (для повышения безопасности статические и динамические модули физически хранятся в разных базах) с поддержкой ACL10, контролем версий и рабочих ветвей,
  • компилятор, преобразующий наборы модулей в псевдокод, исполняемый ядром системы,
  • подсистема привязки модулей к адресам и их группам с поддержкой иерархии страниц, виртуальных серверов и ACL,
  • система экспорта/импорта страниц для редактирования HMTL-верстальщиком,
  • библиотеки (как правило, абстрактные) модулей с возможностью наследования, в т.ч. и множественного.
Модульная концепция сама по себе не является приемлемым решением разделения дизайна и программирования, т.к. любая подобная система рано или поздно в своем развитии включает в HTML-код структуры, все больше и больше напоминающие элементы программирования, иногда -- ОО-программирования. В интернет-системе WebOs Publishing модульная структура реализована так, чтобы сделать максимально удобной работу программиста, ограничив ее так, чтобы обеспечить максимально эффективный экспорт/импорт для HTML-верстки. Даже самый поверхностный анализ показывает, что в общем случае подобная система может включать в синтаксис HTML-разметки только условные операторы; циклы и более сложные структуры, включая структуры данных, должны быть вынесены в программную часть. У модулей есть следующие атрибуты:
  1. идентификатор
  2. статический/динамический
  3. текущая версия
  4. детерминированность (детерминированный, зависящий от адреса (без запроса), зависящий от адреса и запроса, зависящий от адреса, запроса и cookies, индетерминированный)
  5. список модулей, которые данный модуль может включать. Для каждого элемента списка указывается, является ли это включение условным или безусловным
  6. изменяет ли его тело HTTP-заголовки (атрибут формируется как объединение собственного свойства и свойств всех включаемых модулей)
По списку включаемых модулей можно построить дерево вызовов модулей. Именование модулей отделено от самих модулей; один и тот же модуль может иметь несколько имен. Для удобства HTML-верстальщика, полное именование модулей привязано к вложению модулей друг в друга. Вызов модуля может быть осуществлен как относительно текущего модуля, так и по полному имени. У динамических модулей помимо кода, исполняющегося во время формирования HTML-страницы, может быть код, который:
  • исполняется при порождении копии HTTP-сервера
  • до вычисления HTTP-заголовков
  • до начала формирования HTML-кода
  • после формирования HTML-кода
В системе фаза интерпретации статических модулей (т.е. HTML-кода со специальной разметкой) отсутствует; вместо этого она разделена на компиляцию статических модулей, результатом которого является псевдокод в постфиксной записи, и виртуальную машину, исполняющую этот псевдокод. Каждому статическому модулю (точнее -- каждой синтаксически-корректной версии) в системе, таким образом, соответствует линейный псевдокод, исполняемый обычной стековой машиной. Для уменьшения накладных расходов на вызов других модулей, допускается вставка модулей. Кроме того, используя информацию о детерминированности модуля, можно включать в псевдокод HTML-код, соответствующий результату работы подобных модулей. Псевдокод хранится либо в специальной базе, которая реально может находится в общей памяти HTTP-серверов, либо диске. Фаза компиляции не зависит от HTTP-запросов и может быть выполнена даже до старта HTTP-сервера. Библиотека модулей реализует некоторую законченную функциональность сайта. Помимо динамических модулей, библиотека содержит набор статических модулей, реализующих общий для всех сайтов, использующих данную библиотеку, HTML-дизайн. Как правило, библиотека содержит абстрактные модули, которые обязан определить сайт, использующий эту библиотеку. Возможно также переопределение поставляемых в библиотеке модулей. Все вызовы внутри модулей являются виртуальными, так что вызываются фактически определенные модули. Библиотеки можно наследовать, при этом наследующая библиотека может определить не все абстрактные модули; тогда дочерняя библиотека также является абстрактной. Допускается множественное наследование, которое заключается в объединении модулей двух библиотек. Сайт может несколько раз включить использование библиотеки; при этом возможно несколько раз по-разному определить абстрактные и переопределить уже определенные в библиотеке модули. Синтаксически использование библиотеки заключается в порождении потомка библиотеки, которая не содержит абстрактных модулей. Первоначальная разметка HMTL-дизайна должна быть выполнена либо программистом, либо HTML-верстальщиком, понимающим основы внутренней структуры интернет-системы WebOs Publishing. Затем, редактирование происходит по схеме экспорта в реальный HTML, собственно редактирования HMTL-кода и импорта кода в систему. Экспорт может быть осуществлен только в рамках вызова некоторого модуля. При экспорте, вся древесная модульная структура сериализуется в линейную цепочку модулей. Каждый фрагмент HTML-кода этой цепочки имеет информацию о породившем ее модуле и его версии. Всем неименованным модулям присваиваются временные имена; версией неименованного модуля является версия модуля, частью которого он является. Т.к. информация о породивших модулях может быть весьма громоздкой, она может быть закодирована выносом всей разметочной информации в специальную таблицу, а HMTL-код будет содержать лишь метки, ссылающиеся на строки этой таблицы. После редактирования, во время которого HTML-верстальщик обязан сохранить метки в оригинальном состоянии, запускается импорт HTML-страницы. Алгоритм работы следующий:
  1. Если HTML-код фрагмента посимвольно равен HTML-коду статического модуля той же версии, происходит переход к следующему фрагменту.
  2. Если версия HTML-кода, указанная в экспортированной информации, меньше текущей версии, данная ситуация обозначается как конфликт; пользователю отображается новая версия, хранящаяся в базе и его собственная версия. Пользователь выбирает либо одну из двух этих версий, либо на их основе составляет композицию, которая формирует новую версию кода. Весь HMTL-код тут же записывается с новой версией.
  3. Если версия HTML-кода равна текущей версии, в базу вносится новая версия HMTL-кода.
  4. Если версия HMTL-кода больше текущей версии, данная ситуация обозначается как внешний откат версии модуля в процессе редактирования. Пользователю предлагается тот же выбор, что и в п.2.
  5. Привязка модулей к адресам.
К некоторому адресу (или группе адресов -- по регулярному выражению или просто к каталогу) может быть привязан вызов модуля. В вызове могут быть указаны слоты. Помимо явно указанных слотов, модулю передается информация об адресах (включая регистры регулярных выражений). Во время HTTP-запроса сервер определяет, могут ли быть выданы заголовки (это зависит от соответствующего атрибута модуля) и если да, исполняется весь код, предшествующий HTTP-заголовкам, выдаются заголовки, а затем работают тела всех модулей. В некоторых случаях (подобные ситуации должны быть минимизированы) клиенту невозможно отдать HTML, не произведя выполнение всех модулей; тогда клиент ждет до окончания работы последнего модуля. Весь код, который работает после формирования HTML-текста в обоих случаях реально выполняется после выдачи клиенту HTML-кода. Синтаксис внутреннего языка интернет-системы WebOS Publishing и псевдокод описан в приложениях А и Б. В рамках информационной системы WebOS Frontpage был разработан так же компонент интерфейса к интернет-системе WebOS Publishing. В начале необходимо договориться о понятиях. Библиотекой названо объединение некоторой функциональной части и дизайна. Дизайнов в библиотеке может быть любое число; вообще сам дизайн -- это набор некоторых атрибутов (например, язык, палитра и т.д.). Библиотека -- это, с точки зрения объектно-ориентированного подхода, класс. Возможно наследование библиотек, включая множественное наследование. Методы библиотеки могут переопределять друг друга, все методы библиотеки являются виртуальными. Программная часть библиотеки и HTML хранятся отдельно. Далее, хранение программ рассматривается для случая, когда языком программирования библиотек является Perl. Статические модули (т.е. HTML-фрагменты) хранятся в базе данных. Каждый статический модуль может иметь несколько вариантов. Варианты могут быть для каждого атрибута, более того, для некоторого атрибута может быть сказано, что данный фрагмент используется для всех его значений. Например, если атрибуты модуля это к языкк, к цветовая гаммак, к текстовая или графическая версияк, то статический модуль может иметь HTML-фрагменты, которые соответствуют вариантам к русскийк, *, к текстоваяк, к русскийк, *, к графическаяк и к английскийк, *, *. Это значит, что ни для русского, ни для английского нет вариантов, соответствующих палитрам, но для русского есть разные версии для графического и для текстового варианта. На самом деле, не обязательно для какого-то варианта хранить отдельный HTML-фрагмент, можно обойтись условными операторами в каждом из шаблонов:
<a href="http://www.somewhere.ru" vlink=<!--
if eq(design("цветовая гамма"), "синий)
echo "#00ff00" --> >
Разумеется, это только пример - операцию определения цвета надо проводить единожды и записывать в глобальные переменные. Каждому варианту статического модуля присваивается версия. Все изменения варианта статического модуля фиксируются в журнале так, что в любой момент можно извлечь любую версию любого варианта. Несколько человек одновременно могут редактировать один статический модуль. Если при записи версия, которая передается из интерфейса, совпадает с той, которая хранится в базе, то система автоматически создает новую версию варианта и записывает в нее то, что передано из интерфейса, если были сделаны какие-то изменения. Если в базе версия выше, система делает построковое сравнение между HTML-фрагментом из базы той же версии, которая указана в поле к версияк и HTML-фрагментом, который передается из интерфейса. Если изменений нет, то ничего не происходит, а если есть -- полученная построковая разница применяется к последней хранящейся в базе версии. Если при этом все прошло нормально, система просто оповещает об этом пользователя, иначе, если происходит конфликт, система выдает пользователю все три версии (ту, которая хранится в базе с той же версией, что и в поле к версияк, ту, которую передает пользователь и с максимальным номером версии) и последний уже сам пытается самостоятельно понять, в чем проблема. Когда пользователь осуществляет обращение к некоторой странице, система должна вызвать некоторый модуль. Какой это будет модуль - определяет пользователь. Кроме модуля, он может определить, что нужно проставить этому модулю в слоты, причем он может указывать не только статические HTML-фрагменты, но и настоящие вызовы других модулей. Таким образом, адресу соответствует настоящий вызов (вместе с именованными и неименованными аргументами) некоторого модуля. Для каждого каталога пользователю должна быть показана отдельная страница, где он может привязать этим файлам некоторые модули. Выглядит это примерно так. Человек заходит в привязку и видит каталоги "news", "archive" и страницы "index" и "about". Кликнув на index, он видит (и может менять), что эту страницу обрабатывает модуль "mainpage", которому в слот "content" установлен вызов модуля "getarticles" с аргументом "current". Людям, которые не понимают, что такое модули и как они там друг друга вызывают, предоставляется интерфейс импорта-экспорта. Дизайнер должен иметь возможность подредактировать страничку, не влезая в модули, только в HTML. Соответственно, нужно сделать возможность экспорта страницы в специальном формате. В нем каждый шаг обработки виртуальной машиной кода вписывается в комментарии HTML. Пользователь что-то редактирует, не трогая эти специальные комментарии, а потом импортирует этот файл в систему. Система еще раз исполняет код и во время его исполнения сравнивает выдачу кода с тем, что пользователь передал как отредактированную версию. Если в какой-то момент обнаруживается разница, система определяет, из-за чего это произошло. Если это изменение значений каких-то переменных или строк, которые возвращают динамические модули, эти изменения игнорируются. А вот если изменения касаются статических HTML-шаблонов, система автоматически создает новую версию модуля и поступает с ней так же, как и при изменении этого модуля (со всем разрешением конфликтов в стиле CVS). Ясно, что чтобы это сделать, в псевдокомментариях HTML надо записывать не только имена модулей, которые генерируют этот текст, но и их версии. Система информирует об изменениях и предлагает пользователю:
  • эти изменения нужно применить ко всем страницам (тогда все происходит как показано выше),
  • эти изменения надо применить только к текущей странице
Во втором варианте система определяет, нужно ли создавать копию модуля с другим именем. Часто будет возникать ситуация, когда меняется текст, который вставляется через слоты в корневом (по отношении к адресу) модуле в привязке, соответственно надо менять информацию именно в привязке. В систему введено такое понятие как к макетк. Макетом указывается некоторый модуль, который может выступать как корневой, плюс возможно пустое множество слотов со значениями, плюс список всех слотов с комментариями, которым надо обязательно или не обязательно выставить некоторые значения. В каждом каталоге сайта могут иметься свои собственные макеты (т.е. есть глобальные макеты, а есть и локальные). Новый макет можно создать как расширение старого. Т.е. тот же модуль, те же слоты плюс еще некоторые значения некоторых слотов. Когда пользователь хочет создать страницу, он может создавать страницу из макета. Он выбирает его имя, заполняет обязательные слоты, необязательные тоже может установить, и нажимает ОК.

...домик на крыше...,поиск,гостевая книга,cv. Be free, use Linux!