Технология Клиент-Сервер 2002'4

Home Поиск Издания Контакты k-press.ru


Продолжается подписка на наши издания! Вы не забыли подписаться?

Посмотрим правде в глаза

Карл Банк (Karl F. Banke)

Java Server Faces Framework разрабатывают полтора года. Стоило ли ждать? Мы ждали столько, что начали писать свою среду, которую даже можно посмотреть (http://www.iternum.net/i3test). Давайте сравним (предварительную) спецификацию с нашей реализацией, открытой для всеобщего обозрения.

Прежде всего оговорюсь – я люблю стандарты. Они значительно облегчают разработку, давая возможность переноса приложений, снижая привязанность к вендору и, в целом, являются хорошим средством защиты инвестиций в IT. Ещё я люблю писать многоуровневые Java-приложения. Их приятно разрабатывать, они гладко встраиваются в распределенные среды и легко масштабируются. С другой стороны, заказчики не слишком волнуются о распространении и масштабировании. Они хотят, чтобы вы создали такое приложение, какое они хотят – уложившись в срок и бюджет.

Быстрое прототипирование

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

Около года я беспокоился о том, что JSP и сервлеты могут утратить позиции первоклассной среды для Web-разработки. Особенную угрозу представляла среда ASP.NET от Microsoft, предоставляющая в своих встроенных библиотеках большую функциональность. Проверка ввода и обработка обратных вызовов дают подход к разработке, похожий на применяемый в традиционной разработке UI. Одновременно Microsoft, кроме ожидаемых компонентов HTML-форм, предоставила некоторые крайне полезные при Web-разработке компоненты, например, для выбора даты или табличный компонент.

Но, как я уже говорил, я верю в стандарты. Так что теперь мы ставим на Java Specification Request No 127, или Java Server Faces. К сожалению, экспертная группа не сумела выпустить спецификацию, как это планировалось, и наши попытки принять участие в работе этой группы тоже были неудачными – не помню уж, по какой причине, но, может быть, и по нашей собственной вине. Как бы то ни было, долгое ожидание отняло у нас веру в эту конкретную спецификацию, и в июне 2002 года мы начали свою собственную реализацию UI. К концу августа мы практически закончили с дизайном, хотя и близко не подошли пока к тому, чтобы выпустить эту штуку на людей. В этот момент что-то начало происходить и с JSR127.

Что день грядущий нам готовит?

Давайте посмотрим, что есть уже сейчас, осенью 2002 года. Есть туториал, спецификация и эталонная реализация, которые можно скачать с Java Developer Connection. Не забудьте, что спецификация по-прежнему в драфте. Однако она выглядит достаточно полной, что позволяет сделать ряд комментариев о её дизайне и архитектуре. Давайте посмотрим, как она соответствует некоторым из главных целей, изложенных в ней. Не менее интересно сравнить ее с дизайном наших собственных компонентов, обнаруживая поражающие совпадения, а также расхождения.

Ниже изложены мои главные требования к серверным компонентам поддержки интерфейса пользователя. Как оказалось, это практически те самые требования, к которым адресуется спецификация Java Server Faces.

Жизненный цикл как основа

Увы, эталонная реализация, сейчас лежащая на JDC, просто не заработала, хотя я буквально следовал инструкциям. Так что вся приведенная ниже информация взята из спецификации. Первое, что показалось мне интересным – это то, что вся среда накручена вокруг жизненного цикла, а не вокруг компонента. Если запрос обрабатывается, он проходит через 7 фаз жизненного цикла, как показано на рисунке1. В процессе обработки строится дерево компонентов. Затем над компонентами дерева производится несколько операций. Это, в конце концов, приводит к фазе "Render Response", представляющей результаты пользователю.

Рисунок 1. Жизненный цикл, используемый в JSF.

В отличие от спецификации JSF мы сочли более естественным создавать не модель жизненного цикла прохождения запроса, а компонентную модель. В сердце нашей модели лежит страница, содержащая любое количество UI-компонентов. Они образуют дерево, как и в JSF. Но. в отличие от JSF мы особо отделяем определение страницы (или дерева) от его исполнения. С нашей точки зрения, фаза жизненного цикла JSF "Reconstitute Request Tree" излишня, так как мы предполагаем, что в любой пользовательской сессии есть только одна активная страница в данный момент времени. Кроме того, наши древесные структуры по сути статичны после их определения. Это аналогично пользовательскому интерфейсу оконного приложения, где иерархия компонентов интерфейса остается одной и той же, но компоненты можно скрывать или показывать, изменяя атрибуты.

Вторая фаза жизненного цикла JSF – Apply Request Values – используется для преобразования запроса в типизированные значения для компонентов и сохранения их в компонентах. За этой фазой идет фаза "Handle Request Events", используемая для обработки любых событий, сгенерированных на клиенте, и это не сводится к простой отправке формы. Это может быть, например, щелчок по узлу дерева, выбор закладки и так далее. В следующей фазе компоненты проверяются Validator'ами, зарегистрированными для этих компонентов. После успешной проверки значения модели обновляются. До отправки ответа клиенту события могут быть переданы приложению, которое может предпринять соответствующие действия – например, сохранить значения модели в некотором хранилище.

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

JSP Integration

Спецификация JSF определяет инфраструктуру, которая может описывать любую серверную UI-среду. Наша среда, наоборот, разрабатывалась специально для работы с JSP API и сервлетами. Это дает даже где-то более высокий уровень абстракции, чем JSF. Но в реальной разработке этого обычно не видно. На самом деле вывод и обработка простой формы с помощью любой среды может свестись к применению нескольких тегов JSP. Конечно, в разработке бывают ситуации, когда использование тегов JSP становится неуклюжим. Но обе среды позволяют перейти к кодированию на чистой Java. Спецификация JSF требует использования регистрированных сервлетов при обработке запросов. При быстрой разработке это может представлять дополнительные накладные расходы на регистрацию и конфигурацию сервлета, но, как я упоминал, я не смог этого попробовать в работе. Наша среда может работать с чистым JSP, требуя только использования библиотеки тегов для определения и обработки элементов GUI. Мне это нравится.

Один из самых больших недостатков спецификации JSF в том, что она, похоже, не предоставляет поддержки связывания страниц декларативным образом, предпочтительно из самой JSP-страницы. Нет и возможности создания простых последовательностей выполняемых действий, не говоря уж о том, чтобы объединять их. Это разочаровывает. Конечно, понятно, что спецификация JSF не предоставляет некоторого серверного конечного автомата. Но простая поддержка технологических процессов (я имею в виду набор страниц, проходимых в определенном порядке, workflow), подпроцессов (например, перехода на субформу для выбора даты) и проверки выполнения этих процессов (для предотвращения множественных отсылок одной формы) – это практически стандартная составляющая любого процесса создания Web-приложений, основанных на формах. Отсутствие такой поддержки неминуемо приведет к частным решениям либо в рамках отдельных проектов, либо поставляемых определенным вендором.

Templating

Спецификация JSF не требует особого механизма templating-а. Концептуально это совершенно верно, так как JSF не связана с какой-либо презентационной технологией типа JSP. Однако она поддерживает делегированный рендеринг и особые RenderKits. Это позволяет определить рендерер или RenderKit, который в свою очередь, предоставляет механизм templating-а. К сожалению, чаще всего такая реализация будет поставляться разными фирмами-разработчиками – например, поставщиками серверов приложений. Это практически гарантирует привязку к фирме-разработчику. Наша разработка заточена под интеграцию с JSP. Она, таким образом, предоставляет возможности рендеринга, использующего include-механизм JSP, как и основанный на классах механизм делегированного рендеринга наподобие указанного для JSF.

Компоненты с широкими возможностями

Это меня несколько шокировало. Сейчас есть очень мало компонентов и Validator'ов для JSF. Никаких окон с закладками, деревьев, меню или чего-нибудь похожего. Никаких комбинированных окон и никаких Validator'ов, сравнивающих даты. Отсутствует даже начальная поддержка дат и чисел. Конечно, нужно оставить работу и разработчикам средств разработки. Но, с другой стороны, это выглядит как-то неправильно: для использования чего-то примитивного, типа выбора даты, мне придется привязывать себя к какому-то поставщику, возможно, к его IDE, а то и к его реализации сервера. Я не говорю, что у нашей разработки все это есть после месячной работы трех человек! Но я считаю, что все это должно быть частью среды. Иначе у меня не будет ощущения, что мои вложения действительно защищены.

Заключение

В общем, я считаю, что JSF – хорошая основа для серверной поддержки UI на высоком уровне абстракции. В некоторых местах на слишком высоком. Я думаю, что это позор для Sun – не суметь предоставить работающую демо-версию. Но это быстро исправят. Посмотрим, как изменится спецификация к финальной версии. Надеюсь, мне удалось показать, что простора для деятельности здесь больше, чем хотелось бы.

Copyright © 1994-2016 ООО "К-Пресс"