[an error occurred while processing this directive] IT • archiv :: Print

IT • archiv


[an error occurred while processing this directive]

[an error occurred while processing this directive]

Решите проблемы представления в сервлет-ориентированных приложениях

[an error occurred while processing this directive](none) [an error occurred while processing this directive](none)[an error occurred while processing this directive] ::
[an error occurred while processing this directive](none)
[an error occurred while processing this directive]([an error occurred while processing this directive] Кевин Унгер [an error occurred while processing this directive])

[an error occurred while processing this directive](none)

Различные методы представления динамического содержания в приложениях с тонким клиентом.

Java Servlets
PDF versionPDF версия
Обзор
Следует ли Вам использовать сервлеты в чистом виде, страницы JSP, сервлеты с механизмом шаблонов, автоматический компилятор HTML-TO-JAVA , или таблицы стилей XSL для реализации представления в вашем следующем приложении с тонким клиентом? Задача данной статьи — рассмотреть различные методы и помочь Вам выбрать наилучшее решение для вашего проекта. (4300 слов)

В свое время компания Sun Microsystems создала прекрасную технологию Java-сервлетов. (См. Ресурсы.) Все последующие серверные технологии Java основаны на сервлетах. И хотя никто не опровергает факт эффективности сервлетов, ведутся оживленные дебаты о том, какая из сопутствующих технологий является наилучшей для решения проблем представления для Web-ориентированных приложений. Перечислим основные встающие проблемы:

  1. Разделение представления (HTML) и кода, генерирующего динамическое содержание (кода, который обращается к базам данных, создает документы XML, Java-объекты и т.д.)
  2. Соответствие современной компонентной парадигме разработки программ (в целях повышения модульности и эффективности повторного использования кода)
  3. Многократное использование и возможность создания вложенных элементов разметки в контекстах различных страниц (поддержка шаблонов)
  4. Сведение к минимуму времени изучения новых языков создания сценариев и словарей тегов, и обеспечение максимальной совместимости их с инструментальными средствами верстки HTML.

Совмещение кода и представления затрудняет продвижение проекта в обоих направлениях, и вынуждает дизайнера / программиста создавать и программное обеспечение, и дизайн страницы одновременно — два совершенно различных процесса. Еще более худшая ситуация складывается, если отдельные дизайнеры страницы и программисты, работая ад сайтом, не могут работать одновременно, не вступая в "конфликт" друг с другом.

Отступление от объектно-ориентированной компонентной технологии разработки программного обеспечения и невозможность многократно использовать и осуществлять вложение блоков разметки тесно связаны с проблемой смешивания разметки и кода, генерирующего динамическое содержание. Совмещение кода и разметки приводит к тому, что определенный код жестко привязан к определенному форматированию. Это ограничивает возможность формирования инкапсулированных объектов, используемых для генерации содержания. Подобная проблема существует и для компонентов представления (шаблонов): если представление смешано с кодом генерации динамического содержания, у Вас мало шансов многократного использования или включения таких элементов страницы.

Методы, обсуждаемые в этой статье (кроме сервлетов в чистом виде), используя языки сценариев, наборы специализированных тегов разметки и автоматическую генерацию классов Java, расширяют возможности документов HTML для того, чтобы помочь решить первые три проблемы в вышеупомянутом списке. Возможно, это покажется слишком трудным для непрограммистов — учиться использовать такой инструментарий; однако нужно помнить, что в противном случае мы столкнемся с проблемой превращения программистов в дизайнеров! Дизайнеры полагаются на инструментальные средства верстки HTML, поэтому новые теги и сценарии должны быть как можно более дружественными к этим инструментам.

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

Последующее обсуждение затрагивает некоторые основанные на сервлетах методы представления Web-страниц в контексте вышеупомянутого списка проблем. Другими словами, эта статья обсуждает основные методы решения проблем представления, используя небольшие примеры систем, решающих эти проблемы. Некоторые из доступных или разрабатываемых основанных на сервлетах шаблонных механизмов и серверных Java-frameworks в данной статье не упомянуты.

Простые сервлеты

Сервлеты являются значительным улучшением тяжеловесной модели программирования применяемой в сценариях CGI, которая использует отдельные серверные процессы для обработки каждого нового запроса . Модель обработки запросов, применяемая в сервлетах, использующая легковесные потоки Java (один поток на один клиентский запрос), намного более эффективна. Она также позволяет реализовать сохранение объектов между запросами, без использования базы данных или дисковой памяти. Сервлеты остаются основной технологией для обработки клиентских запросов на сервере Java .

Однако, замена CGI-скриптов на Java-сервлеты никак не затрагивает проблему HTML-разметки, глубоко внедренной внутрь кода, вне зависимости от того, Perl или Java генерирует содержание страницы. Сервлеты обычно используются при динамической генерации страниц HTML для интерактивных Web-сайтов; они агрегируют текст HTML и выводят его в в объект java.io.PrintWriter. Этот утомительный процесс приводит к совмещению представление и логики генерации содержания. (Средства работы с текстом в Perl, фактически, делают его наилучшим языком для подобного использования) Для достижения необходимого результата либо Web-дизайнер должен уметь программировать на Java, либо Java-программист должен освоить Web-дизайн.

Формирование компонентов представления с помощью одних сервлетов возможно, особенно, если проект использует некоторый механизм для включения и многократного использования блоков HTML, в которые динамическое содержание могло бы быть внедрено при обработке запроса. Остальная часть методов полагается на добавление некоторых механизмов создания шаблонов к стандартным сервлетам. Вы можете рассматривать их в качестве альтернатив при разработке своего собственного подхода к созданию шаблонов Web-станиц.

Шаблонные механизмы

Использование шаблонов — методика, которая расширяет статические документы HTML, добавляя сценарии или заказные теги, либо автоматизируя создание классов Java, представляющих документы. Шаблон, в этом случае, представляет собой блок расширенного HTML, который благодаря Java-манипуляциям или внедренным сценариям, облегчает включение динамически сгенерированного содержания на этапе выполнения. Остальная часть этого раздела кратко описывает три типичных шаблонных механизма, распространяемых на условиях Open Source.

WebMacro

WebMacro предоставляет минимальную инфраструктуру для реализации архитектуры Model/View/Controller (MVC) в контексте Web. (См. Ресурсы.) Эта инфраструктура облегчает сопоставление запросов и шаблонов, выполнение этих шаблонов, а также обеспечивает шаблоны информацией о пользовательской сессии и любыми данными бизнес-объектов, которые они должны использовать. Язык созданий сценариев позволяет шаблонам произвольным образом обращаться к объектам бизнес-логики. В терминологии MVC, данные бизнес-объектов составляют модель (model), шаблоны — виды (views), а код, который сопоставляет запросы и шаблоны и выполняет их — контроллер (controller).

Основная особенность WebMacro — это поддержка простого языка создания сценариев (с синтаксисом, похожим на Perl). Создатель WebMacro, Джастин Веллс (Justin Wells), называет его "языком шаблонов", отличая его от развитого языка создания сценариев. Данный язык поддерживает:

  • Простое ветвление
  • Выполнение итераций по спискам объектов
  • Обращение к данным, сгенерированным внешними Java-объектами
  • Включение других файлов шаблонов или любого текстового файла (статическое включение)
  • Синтаксический разбор файлов шаблона (динамическое включение)
  • Локальные переменные

WebMacro широко использует Java reflection API(см. Ресурсы) для установления топографии объектов. Это дает шаблонам возможность обращаться к данным без необходимости в специальном синтаксисе для объявления объектов, привязывания локальных идентификаторов к классам объектов и их свойствам, получения и изменения свойств объектов. Шаблон может просто обратиться к глубоко внедренному полю (или методу), используя разделенные точкой идентификаторы, соответствующие определенному полю или методу объекта.

Наиболее простой способ использовать WebMacro — создать подкласс класса WebMacro WMServlet WMServlet и переопределить метод handle(), который получает объект ContextContext в качестве параметра и возвращает объект Template:

org.webmacro.Template handle(org.webmacro.servlet.WebContext)

Функция handle() выполняет следующие шаги:

  1. Использует информацию объекта WebContext (включая объект HttpServletRequest) для определения того, какой шаблон использовать
  2. Помещает любые данные, необходимые выбранному шаблону, в контекст
  3. Получает анализируемый шаблон и кэширует его, если его еще не в кэше
  4. Возвращает шаблон системе WebMacro, которая выполняет его и возвращает результат клиенту

WebMacro полностью удаляет HTML из Java-кода и внедряет серверные сценарии в файлы HTML, преобразовая их в файлы шаблонов WebMacro. Это делает HTML более сложным, и слегка сокращает возможности инструментов верстки HTML. Дополнительные накладные расходы для авторов HTML компенсируются увеличением производительности труда программистов в результате снятия с них бремени верстки HTML. Простой, но гибкий механизм шаблонов WebMacro допускает многократное использование шаблонов, а механизм динамического включения позволяет создавать вложенные шаблоны.

Добавление языка сценариев — простите, "шаблонов" — затрагивает фактор времени изучения технологии для HTML дизайнеров. WebMacro минимизирует масштабы этой проблемы, сохраняя язык простым, но обладающим достаточными возможностями, чтобы обработать любое кодирование, необходимое в шаблонах.

WebMacro недавно был повторно реализован в рамках проекта Apache Jakarta (см. Ресурсы) под названием "Velocity".

FreeMarker

FreeMarker (см. Ресурсы) очень похож на WebMacro. Он реализует MVC, точно так же, как это было описано для WebMacro. Основные различия:

  • Язык создания сценариев в системе FreeMarker более сложен, чем WebMacro: он имеет функции и логические выражения.
  • Язык создания сценариев в системе FreeMarker имеет более тяжеловесный синтаксис
  • Механизм кэширования шаблонов FreeMarker автоматически обновляет кэш, так что измененные шаблоны подключаются без перезагрузки сервиса.

Обе системы превосходно справляются со всеми четырьмя проблемами представления, однако WebMacro делает это лучше. Основная цель системы поддержки шаблонов состоит в том, чтобы отделить программирование от разметки представления, так что выгода от более сложного языка создания сценариев в системе FreeMarker сомнительна — особенно, если рассматривать проблемы 1 и 4 из вышеуказанного списка. Отсутствие в WebMacro "мощных" возможностей создания сценариев — преимущество, а не недостаток.

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

XMLC

Я противопоставил способ, с помощью которого простые сервлеты поддерживают динамические страницы (внедрение HTML внутрь кода Java), способу, при котором шаблонные механизмы WebMacro и FreeMarker внедряют определенного вида сценарии внутрь файлов HTML. Подход XMLC абсолютно иной. (См. Ресурсы.) XMLC — специализированный Java-компилятор для HTML (или XML) файлов шаблона. В самом деле, XMLC компилирует простые файлы HTML в файлы Java-классов, создавая отдельный класс для каждого шаблона HTML.

XMLC решает эту задачу, используя HTML-атрибут ID в сочетании с Объектной Моделью Документа XML (Document Object Model — DOM). (Атрибуты ID — идентификаторы, уникальные в пределах документа). Шаблоны HTML компилируются в классы Java; каждый класс содержит представление документа в виде DOM. Классы имеют методы доступа для всех элементов HTML с атрибутами ID. Код Java, управляющий документами, использует методы доступа для изменения шаблона, добавляя или изменяя соответствующие элементы. XMLC также использует элемент SPAN для вставки или изменения текста, и атрибут CLASS для группировки наборов элементов.

Классы шаблона реализуют интерфейс org.enhydra.xml.xmlc.html.HTMLObject и расширяют класс org.enhydra.xml.xmlc.html.HTMLObjectImpl. Если Вы решили испробовать XMLC, обратите внимание, что, возможно, исходный текст, приведенный в руководстве, не будет работать, так как классы будут не в состоянии унаследовать HTMLObjectImpl. Реальный код, сгенерированный XMLC, делает это правильно. (См. Ресурсы). Код сервлета для заполнения шаблона, выполняет следующие шаги:

  1. Создает объект шаблона который соответствует обрабатываемому запросу
  2. Добавляет динамическое содержание к дереву DOM объекта шаблона, используя методы доступа
  3. Вызывает метод HTMLObject.toDocument() для получения результирующего текстового представления

XMLC раньше являлся частью свободно-распространяемого сервера приложений Enhydra, построенного на базе Java/XML (см. Ресурсы); теперь благодаря возросшей популярности, это — автономный проект. В данный момент на сайте Enhydra.org разрабатывается новый проект, называемый Rocks Presentation Framework (см. Ресурсы); выпуск альфа-версии намечен на конец ноября. Rocks — один из нескольких проектов, в которых делаются попытки спроектировать и реализовать всестороннюю инфраструктуру представления MVC; он основан на XMLC.

Одна из целей проекта XMLC описана в Руководстве пользователя XMLC следующим образом :

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

В данном фрагменте заключена мощная концепция. Она означает, что HTML-страницы, используемые дизайнером при создании макета, станут шаблонами представления и будут иметь силу на всех стадиях разработки проекта. Это также означает, что дизайнеры могут работать независимо в течение долгих периодов времени, и только когда очередной крупный фрагмент макета их удовлетворяет, они отдают его программистам. Хотя даже незначительные изменения в файлах HTML требуют перекомпиляции, XMLC имеет удачный механизм авто-компиляции, которая позволяет сконфигурировать приложение так, чтобы всегда использовать самые последние версии шаблонов без необходимости перезапуска.

XMLC лучше всех (из трех описанных шаблонных механизмов) справляется с задачей отделения кода от представления, потому что его шаблоны — чистый HTML, без всякого дополнительного кода. Это полностью снимает проблему роста времени обучения. Автор HTML-документа должен изучить только, как использовать атрибуты ID и CLASS, а также элемент SPAN — все они являются стандартными средствами HTML. Это также позволяет использовать в полную силу инструменты верстки HTML.

У XMLC есть одна проблема — отсутствие поддержки вложенных шаблонов. Возможно, Rocks Presentation Framework добавит такую поддержку.

JavaServer Pages (JSP)

JavaServer Pages (см. Ресурсы) — ответ Sun на технологию Active Server Pages (ASP), разработанную Microsoft. JSP и ASP — сходные технологии: обе добавляют к HTML специальные теги, язык создания сценариев, и способность обращаться к внешним программным компонентам. Sun продвигает JSP как стандартный внешний интерфейс к серверам на базе Java, включая средства Enterprise Java (J2EE). Вы можете использовать JSP как шаблонный механизм (более подробно это будет рассмотрено позже), но особенности этой технологии позволяют рассматривать ее и отдельно.

Права на спецификации JSP и сервлетов, а также API принадлежат Sun, однако официальный пример реализации этих API, Tomcat (см. Ресурсы), является частью проекта Apache Jakarta, основанного Apache Software Foundation.

В двух словах, файл JSP — это HTML (или XML) с включением любых комбинаций следующих элементов:

JSP/сервлет-контейнер выполняет следующие шаги, при обработке запроса на доступ к JSP-странице:

  1. Страница JSP преобразовывается в исходный текст Java-сервлета
  2. Исходный текст сервлета компилируется в class-файл
  3. Класс сервлета загружается JVM сервера
  4. Сервлет выполняется в новом потоке

Шаги с 1-го по 3-й выполняются только один раз. JSP может быть заранее преобразована и откомпилирована; в противном случае, она конвертируется и компилируется, в момент первого обращения к ней. После первоначальной загрузки class-файл остается в памяти пока запущен сервлет-контейнер.

Разработчик страницы имеет возможность использовать весь арсенал средств Java внутри файла страницы, сочетая скриптлеты, HTML и специальные теги JSP. Его потенциал ограничен только границами платформы Java. Однако, этот потенциал должен использоваться аккуратно, чтобы избежать появления громоздкой и неудобной в сопровождении системы. Более подробное обсуждение отрицательных сторон JSP приведено в статьях Джейсона Хантера (Jason Hunter) "The Problems with JSP" и "Reactions to 'The Problems with JSP.'" (См. Ресурсы)

Подходы к использованию JSP: Модель 1 и Модель 2

Существует два общих подхода к проектированию приложений на базе JSP, которые получили название архитектур "Модель 1" и "Модель 2".

Модель 1 более простая (и более проблематичная) из них. Ее компоненты — страницы JSP и JavaBeans. Она полагается непосредственно на страницу JSP в части выполнения всей логики по обработке запроса и данных пользовательской сессии. Вы можете обращаться к внешним данным, вызывая beans, но большая часть прикладной логики расположена на странице. Нетривиальные приложения, реализованные с использованием Модели 1, с большой степенью вероятности будут представлять собой бессистемную и неудобную для последующей поддержки свалку Java-кода и разметки (так называемый "синдром вороньего гнезда" — rat's nest syndrome).

Модель 2 более интересна и более полезна. Она добавляет еще один компонент, отсутствующий в Модели 1 — сервлет-контроллер, и реализует, таким образом, парадигму MVC. При использовании Модели 1 не остается иного выхода, кроме как помещать логику обработки запроса и сессии на страницу JSP; Модель 2 оставляет эту обработку сервлету-контроллеру. Сервлет-контроллер — внешний интерфейс для обработки запросов — он вызывает соответствующие JavaBeans для генерации содержания и страницы JSP для отображения этого содержания. Это соответствует шагам, которые выполняет метод handle() в системе WebMacro.

Хотя Модель 2 и является значительным усовершенствованием Модели 1, кроме случая простейших приложений, однако Модель 2 — не панацея от синдрома rat's nest. Модель 2 все-таки оставляет возможность включения большого количества неуместного кода, который может сделать ваши страницы JSP уродливыми, а приложение — негибким и непереносимым. Обычный прием — вложенные таблицы HTML, содержащие динамическое содержание — будут наносить ущерб страницам, использующим Модель 2, но не использующим дополнительные механизмы и инфраструктуру для построения JSP.

JSP как шаблонный механизм

До появления спецификации JSP 1.1 (выпущенной в начале 2000 года), свободное использование Java скриптлетов в JSP-страницах, было обусловлено реальной потребностью. Страницы JSP, содержащие весь этот код, с трудом могут рассматриваться в качестве "шаблонов" представления — они, фактически, представляли собой файлы исходных текстов логики представления. Версия 1.1 предоставила мощную возможность расширения системы тегов разметки (tag extension), которая позволяет определять пользовательские теги и связывать их с классами Java. Используя дополнительные теги, Вы можете перемещать скриптлеты в классы-обработчики этих тегов. Вы можете также использовать JSP в качестве шаблонного механизма, разрабатывая наборы тегов, обработчики которых содержат весь код Java, который иначе пришлось бы включать в страницы JSP. Хотя это не устраняет возможность использования большого количества скриптлетов на странице, это почти устраняет подобную потребность.

После выпуска JSP 1.1, многие производители серверов приложений стали поставлять обширные библиотеки дополнительных тегов вместе с их серверами (включая BEA WebLogic и Allaire JRUN). Производители также создают средства разработки, поддерживающие JSP (например, IBM WebSphere Studio). Эти библиотеки тегов и инструментальные средства значительно повышают качество приложений на базе JSP.

Подобно WebMacro, JSP имеет механизмы динамического и статического включения, которые позволяют создавать вложенные шаблоны и поддерживать многократное использование. JSP также предоставляет обработчикам тегов доступ к механизму динамического включения через объект PageContext, доступный всем обработчикам. Используя библиотеки тегов и механизм включения, Вы можете формировать интерактивные сайты с большим объемом динамического содержания на базе JSP-страниц, не содержащих Java-кода вообще, либо использующего его в минимальном количестве. Хотя накладные расходы на обучение использованию библиотек расширенных тегов могут быть значительными, это все-таки является более предпочтительным подходом, нежели создание файлов, в которых HTML комбинируется с кодом на развитом языке программирования, поскольку такие "страницы" вынуждают дизайнера программировать или программиста заниматься разметкой и дизайном.

Jakarta Struts

Система Struts (см. Ресурсы), другая часть проекта Jakarta, является аналогичной по структуре системе Rocks, однако Struts содержит реальный код. Struts — реализация MVC, которая использует страницы JSP в качестве компонента представления (view). Инфраструктура Struts включает реализацию сервлета-контроллера (controller), с помощью которого осуществляется отображение запросов, страниц JSP и действий (actions). (Действия, в данном случае, управляют состоянием модели.) Другая важная часть системы — обширная библиотека тегов. Эта библиотека, совместно с сервлетом-контроллером и собственными служебными классами и интерфейсами, представляет собой наиболее устойчивое решение задач представления из описанных.

По умолчанию, Struts читает XML-файл конфигурации, который определяет порядок отображения запросов к действиям. Каждое из отображений, определенных в файле, используется для создания и загрузки класса ActionMapping. Если файл существует, то это происходит при запуске; в противном случае, Вы можете написать свой собственный код и загружать объекты самостоятельно. Объекты ActionMapping связывают URI запроса с классом Action, который реализует конкретное действие для этого запроса, а также (необязательно) с bean-компонентом ActionForm, который сохраняет данные из формы запроса.

Для обработки каждого запроса, сервлет-контроллер выполняет следующую последовательность шагов:

  1. Выявляет соответствие URI запроса объекту ActionMapping.
  2. Если этот объект определяет ActionForm bean, пытается получить экземпляр этого bean из пользовательской сессии (или запроса, в зависимости от области действия формы). Если такой bean не найден, создает его и добавляет к сессии (запросу).
  3. При использовании ActionForm bean, вызывает методы установки каждого из свойств компонента, для которого присутствует одноименный параметр запроса. (Этот механизм поддерживает многостраничные формы.)
  4. Если в ActionForm bean определена необходимость проверки значений, вызывает его метод validate().
  5. Если метод validate() возвращает массив сообщений об ошибках, сохраняет этот массив как параметр запроса и передает управление назад входной форме (указанный в объекте ActionMapping). Сообщения об ошибках будут обработаны тегом <struts:errors /> во входной форме.
  6. Если в объекте ActionMapping нет ссылки на экземпляр класса Action, создает его.
  7. Вызывает метод class's perform() класса Action.
  8. Если метод perform() возвращает не пустой объект класса ActionForward, передает управление указанной странице JSP, для генерации соответствующего ответа на запрос.

Метод perform() класса Action обычно выполняет такие шаги:

  1. Проверяет корректность пользовательской сессии
  2. Управляет компонентами бизнес-логики для обработки текущего запроса
  3. Обновляет все beans, необходимые для формирования содержания следующей страницы
  4. Возвращает объект ActionForward (полученный из объекта ActionMapping ) который указывает на следующую страницу JSP

Страницы JSP, созданные для Web-приложений, использующих Struts, напоминают обычные Web-станицы — никаких кусков Java-кода и трудночитаемого синтаксиса, в основном только теги, подобные HTML. Кроме того, структура Struts обеспечивает по крайней мере частичное решение проблем, остающихся нерешенными у других инструментов формирования логики представления. Вдобавок к механизму отображения запросов формам и классам действий, Struts обеспечивают поддержку локализации, проверки правильности входных данных, обработки ошибок, обработки входных данных форм и организации многостраничных форм.

Jakarta Struts — очень молодой проект, развивающийся в соответствии с концепцией Open Source. Он был официально начат 31 мая 2000 года; в его основе лежит ядро, созданное Крейгом МакКлэнехеном (Craig McClanahan). Struts — фреймворк для реализации логики представления для Web-приложений.

Шаблоны XSL

XSL (Extensible Stylesheet Language — Расширяемый Язык Стилевых таблиц) в последнее время стал очень популярной XML-технологией. (См. Ресурсы.) XSL — язык для определения таблиц стилей с помощью синтаксиса XML. Таблица стилей XSL управляет преобразованием XML-документа c одного XML-языка в другой XML-язык. В частности стилевая таблица XSL может определять, каким образом отобразить данные, содержащиеся во входном документе XML, на Web-станице, описывая необходимые преобразования и добавляя форматирование для генерации целевого HTML-документа.

Элементы XSL, определяющие операции преобразования, представляют собой подмножество языка XSL, называемое XSLT (XSL Transformation). Другое подмножество языка, XPath, обеспечивает произвольный доступ к любой части XML-документа. XSL добавляет элементы форматирования к XSLT и XPath.

Аналогично различным XML-парсерам, присутствующим на рынке, теперь доступны и различные виды XSL-процессоров. Поскольку спецификация XSL и сопутствующие спецификации (XPath и XSLT) вышли на приемлемый уровень, в Сети начали появляться приложения, использующие XSL-процессоры. Эти приложения динамически генерируют содержание XML на стороне сервера. К этому содержанию на сервере (иногда на клиенте) применяются стилевые таблицы XSL, в результате чего получаются страницы HTML, отображаемые клиентскими броузерами.

Приложения, использующие XSL для представления страницы, полагаются на архитектуру, которая по существу генерирует "чистые" данные в форме XML; заключительный шаг в такой архитектуре — стилизация данных. Этот ориентированный на данные тип приложений работает лучше всего в среде "публикации локументов", когда содержание является в большей степени статическим. В этом случае можно использовать XSL для выдачи информации различным типам клиентов. Вы можете форматировать один и тот же XML-документ для Web-броузеров, PDA, тостеров, и т.д, применяя различные таблицы стилей XSL.

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

Компоненты с реальным кодом (сервлеты, классы, beans) таких ориентированных на данные приложений генерируют документы XML в ответ на запросы. Работа Java-кода выполнена, когда сгенерирован XML, однако гораздо более объемная обработка требуется для преобразования XML-документа с динамическим содержанием в Web-станицу. Например, элементы XML должны быть отсортированы и отфильтрованы, а эти действия часто параметризуются другими элементами. Такой уровень обработки требует некоторого уровня программистского опыта. Шаблонные механизмы и решения на базе JSP могут использовать Java-сценарии для генерации заранее отсортированных и отфильтрованных данных. Таблицы стилей XSL не могут делать этого, потому что на момент преобразования XML уже сгенерирован.

Одним словом, стилевые таблицы XSL, используемые для представления страниц с динамическим содержанием, переполнены кодом, который фильтрует, сортирует, и форматирует данные исходного XML-документа. Более того, этот код выглядит уродливо и неуклюже, потому что таблицы XSL — это прежде всего XML-документы, а XML разрабатывался для представления данных, а не языков программирования. Поэтому и не удивительно, что при реализации конструкций программирования в виде основанного на тегах синтаксиса XML в результате получается код, который сложен для чтения и понимания. Поэтому для Web-дизайнера очень сложно перейти к программированию XSL.

Из положительных моментов следует отметить, что использование XSL приводит к чистому разделению бизнес-логики и логики представления, так что Вы можете разрабатывать компоненты для управления и обновления модели независимо от компонентов представления (стилевых таблиц XSL). К тому же XSL имеет директиву статического включения (динамическое содержание уже было сгенерировано на момент обработки XSL), что позволяет получать страницы, путем применения нескольких файлов шаблонов XSL.

Заключение

Многие коммерческие и некоммерческие инструменты претендуют на решение проблемы формирования представления страниц; многие из них твердо придерживаются архитектуры MVC. Иная подобная система, которую стоит отметить в этой статье, это проект Apache Turbine (см. Ресурсы), часть Java Apache Project. Turbine — еще одна полноценная, основанная на MVC система для построения Web-приложений, более объемлющая, нежели Struts. Часть функциональных возможностей Turbine пересекается с сервисами, которые обеспечиваются серверами приложений J2EE.

Turbine представляет собой реализацию концепции комбинирования методов представления. Нет никаких причин для того, чтобы не использовать одновременно несколько различных методик; система Turbine предназначена поддержки WebMacro/Velocity, FreeMarker, JSP, а также Cocoon (система публикации на базе XML/XSL, разрабатываемая в рамках Apache XML Project)

Более простым примером гибридной технологии могла бы быть система на базе JSP Модели 2, которая обрабатывала бы некоторые запросы, вызывая beans (или передавая управление сервлету) для выполнения XSL-обработки и возвращала окончательный результат в виде HTML. Такие гибриды, вероятно, станут более популярными, поскольку Web-приложения на основе сервлетов продолжают распространяться.

Если Вы решили, что ни одна из доступных систем не решает специфических проблем представления, стоящих перед Вашим приложением, Вы можете создать собственный механизм. Если Вы решили, что ни JSP, ни любой из шаблонных механизмов не решает ваших задач по формированию страниц, Вы можете также реализовать все самостоятельно. В любом случае, существует ряд общих требований, которые следует учесть:

Об авторе

Кевин Унгер (Kevin Unger), старший программист в Niku Corp, является членом команды, которая создает системы уровня предприятия, для поддержки взаимодействия различных программных продуктов для рынка сферы услуг. Кевин занимался разработкой программ на Java в течение двух лет, и в течение семи лет — на C++. Он имеет степень бакалавра Computer Science Нью-Хемпширского Университета.

Ресурсы

Reprinted with permission from the November 2000 edition of JavaWorld magazine. Copyright © ITworld.com, Inc., an IDG Communications company.
View the original article at: http://www.javaworld.com/javaworld/ jw-11-2000/jw-1103-presentation.html

[an error occurred while processing this directive]
[an error occurred while processing this directive] Перевод на русский © Антон Никитин, 2001
< Вернуться на caйт :: Copyright © 1999 — 2010, IT • archiv.