Rambler's Top100 Бизнес
Время - деньги!

Time is money!

  Rambler's Top100

russian  english

Глава 3. Структура и логика

Начнем, пожалуй, с соотношения следствий главных требований к Service Pages Addon и реальных возможностей как разработчиков(нас) и пользователей(вас).

Одним из требований к Service Pages Addon являлось увеличение функциональных возможностей web-интерфейса до максимально возможного уровня. Изучение свободно доступного прикладного програмного интерфейса web-api позволяет убедиться в возможности удовлетворения этого требования не смотря на то, что часть библиотеки классов API не является документированной.

Не менее важным требованием было улучшение визуальной привлекательноти интерфейса пользователя. Возможные рамки ограничивающие это требование, определялись доступным п/о как серверной так и клиентской части. Этот вопрос уже

обсуждался ранее.

И наконец, приложение должно было обладать достаточной гибкостью, чтобы угодить всем возможным пожеланиям потребителя еще на стадии разработки. Для удовлетворения этого требования как нельзя кстати пришлось бурное развитие XML-совместимых стандартов описания структур. Речь идет как о структуре программы, так и о структуре данных - именно использование для того и другого одного и того же языка разметки позволяет повысить гибкость всего приложения в целом. К сожалению для программирования серверной части использовался XML-совместимый mix языков JAVA и JSP, в связи с чем использование единого формата для описания даных и действий не представлялось возможным. Несмотря на это, использование предопределенных xml-сущностей и четкого перечисления вариантов написания Java-блоков позволило создавать исходный текст форм практически только тэгами xml, а части java-кода выходящего за рамки установленного базиса с использованием специальных конструкций и вставок <![CDATA[...]]>.

Итак, пройдемся по шагам процесса разработки проекта. Сначала коснемся вида web-интерфейса и рассмотрим эскиз главной страницы пользователя в Service Pages Addon. Как и в Service Pages главная страница состоит из нескольких фреймов.

  • index.xml должен иметь вид максимально схожий с левой панелью Service Desk Client
  • View.jsp верхняя часть; должна содержать элементы управления видом.
  • View.jsp(iframe) нижняя часть содержит inline-фрейм(iframe) со ссылкой на ViewBy.jsp

Набор фреймов(frameset) описывается в файле index.html и состоит из ссылок на файлы index.xml и overview.html. При нажатии кнопки-ссылки в левом фрейме, содержимое правого фрейма заменяется на содержимое View.jsp, выводящий при выполнении таблицу, верхняя часть которой содержит элементы управления видом, а нижняя inline-frame ссылающийся на ViewBy.jsp. При этом, скрипту ViewBy.jsp в формате HTTP POST передается необходимая служебная информация. В свою очередь ViewBy.jsp генерирует листинг в XML-совместимом формате, после чего этот листинг доставляется броузеру, трансформируется в формат HTML с помощью стилевого листа table.xsl и отображается. Применение таблиц стилей xsl позволяет изменять оформление в соответствии с пожеланиями конкретного заказщика и сократить количество ошибок за счет раздельной разработки модели и вида данных.

Файл index.xml до отображения преобразуется встроенным в броузер XSLT-транслятором в формат HTML во время выполнения, для чего необходима поддержка броузером клиента XSLT. Для трансформации с сервера закачивается стилевой лист index.xsl, ссылка на который имеется в index.xml.

В действующем приложении это будет выглядеть примерно так:

В качестве примера использован снимок с экрана действующего web-интерфейса с использованием Internet Explorer 6.0 [

7], в данном случае это список персон Service Desk . Изображения на элементах управления позаимствованы из каталога иконок Service Desk Client и преборазованы в формат .png с помощью утилиты convert из пакета ImageMagic.

Сложности, с которыми пришлось столкнуться при реализации листинга:

  • Открытая часть API предоставляет только идентификатор и название фильтра, но не алгоритм фильтрации, в связи с чем приходится вручную создавать карту идентификатор-действия, Такой механизм был реализован в упрощенном варианте с учетом действия по умолчанию при отсутствии ключа(идентификатор,тип объекта) в карте.
  • В связи с тем, что количество типов объектов подлежащих просмотру достаточно велико [8], создание отдельного кода для каждого типа объекта представляется достаточно сложным.

Положительным моментом, однако, является встроенная в java-машину интроспекция, что позволяет задавать классы и методы классов по их строковым названиям во время выполнения, после чего использовать для вызова в специальном контекстном объекте и приведения типов возвращвемых значений.

Теперь разберемся с процессом создания формы редактирования объектов. В отличие от разработки страницы листинга в даном случае появляются веские обстоятельства для применения несколько иного дизайна.

Внешний вид формы редкатирования выбирался максимально сохжим с видом в Service Desk Client. В соответствии с этим, использовалась группировка элементов управления как показано на нижележащем эскизе.

Процесс разработки страниц редактирования объектов, как уже отмечалось, разбивается на несколько частей. Исходный код в xml-совместимом формате содержит описание частей страницы редактирования с использованием нескольких пространств имён. Пространство имен sd: используется стилевым листом для преобразования данных XML в HTML во время выполнения. Таким образом можно менять внешний вид страницы не изменяя исходных текстов. Пространство sdjsp: используется для описания логики приложения не затрагивая его стиль. Тэги, не имеющие явного указания пространства имен подразумеваются общими, т.е. могут обрабатываться как на этапе начальной компиляции, так и во время выполнения.

На этом рисунке схематично изображены основные стадии компиляции/выполнения. К названиям файлов исходных текстов и результирующих jsp-программ применяются следующие соглашения: файлы исходных текстов должны именоваться ce_ClassName.xml, где ClassName - название класса объекта, подлежащего редактированию, например, ce_Incident.xml, причем регистр символов должен совпадать. На рисунке выше, файл с исходным текстом ce_A.xml содержит описание формы редактирования объекта класса A. Стилевой лист create_edit_jsp.xsl содержит информацию, необходимую для преобразования ce_A.xml в ce_A.jsp. При этом обрабатываются, и, как правило, преобразуются в информацию для формы тэги пространства имен sdjsp:. Тэги пространства имен sd: при этом остаются не тронутыми. Тэги с неопределенным пространством имен не соответствующие какому-либо пространству имен остаются нетронутыми по умолчанию, но могут и обрабатываться на этапе компиляции, поэтому при их применении создателю исходного кода следует проконсультироваться с создателями стилевого листа jsp и внешнего облика. Стилевой лист внешнего облика хранится в файле create_edit.xsl и подгружается по требованию броузером обрабатывающим результирующий xml-код, сгенерированный скриптом ce_A.jsp. Результирующий xml-код, естественно, содержит только тэги без пространства имен и пространства sd:. В результате в кэше броузера создается html-документ, который в последствие и отображается.

В действующем приложении это будет выглядеть так:

В качестве примера использован снимок с экрана действующей формы редактирования, в данном случае это форма редактирования инцидента.

Естественно было бы предположить невозможным создание базиса програмных элементов, удовлетворяющих любые потребности. Для решения этой проблемы,

как упоминалось выше, предоставляется возможность делать вставки java-кода. Эта возможность будет описана в следующей главе.



[7] К сожалению, этот броузер не распознает прозрачный фон картинок .png и заполняет его белым цветом.

[8] по сравнению с количеством типов объектов подлежащих редактированию