 |
Технология Клиент-Сервер 2002'4
|
|
|
JavaServer Faces – упрощение Web-разработки
Технология JavaServer Faces должна упростить создание интерфейса пользователя
для JavaServer-приложений. Программная модель JSF должна позволить программистам
разного уровня подготовленности быстро и просто создавать Web-приложения с
помощью: сборки страницы из многократно используемых UI-компонентов, подключения
этих компонентов к источнику данных приложения и обработки генерируемых клиентом
событий серверными обработчиками.
JSF включает:
-
Набор API для: представления UI-компонентов и управления их
состоянием, обработки событий и проверки ввода, навигации по странице и
поддержки интернационализации.
-
Набор тегов JSF для описания JSF-интерфейса на
JSP-странице.
По замыслу, JSF должна быть максимально гибкой, расширяя
возможности существующих технологий, но не привязывая разработчика к конкретному
языку разметки, протоколу или клиентскому устройству. Классы UI-компонентов,
входящих в JSF, инкапсулируют функциональность, но не клиентское представление,
что позволяет организовать отрисовку интерфейса практически на любом устройстве
вывода. Комбинируя функциональность UI-компонентов с пользовательскими
отрисовщиками (рендерерами), разработчик может создавать собственные теги,
рассчитанные на конкретное клиентское устройство. Изначально JSF включает
рендерер и библиотеку тегов для HTML-клиента.
Поскольку простота использования является главной заявленной
целью, архитектура JSF четко различает логику и представление приложения, в то
же время позволяя легко связать презентационный уровень с кодом приложения.
Такой дизайн позволяет участвовать в разработке не только программистам, но и
Web-дизайнерам, не имеющим программистских навыков даже на уровне создания
скриптов.
JavaServer Faces разрабатываются в рамках Java Community
Process (JSR-127). Сейчас несколько вендоров средств разработки уже объявили о
поддержке готовящегося стандарта в своих продуктах. Подробнее узнать о JSF, а
также о том, на какой стадии находится разработка сейчас, можно на странице http://jcp.org/jsr/detail/127.jsp.
Однако споры вокруг JSF и концепций, закладываемых в основу этой технологий,
продолжаются. Очевидно, JSF предстоит пройти еще немалый путь, прежде чем она
завоюет признание. Мы решили привести здесь перевод сеанса вопросов и ответов,
прошедшего на Java Live! в середине октября. На вопросы отвечают Craig
McClanahan (CM), лидер разработки спецификации JSF (сейчас она в стадии Early
Access), и Amy Fowler (AF), бывший лидер разработки того же самого.
* * *
Q: Как насчет создания общей GUI-среды для Swing и JSF?
Зачем нужны две разных библиотеки, если разработчикам нужны одни и те же
деревья, ползунки и кнопки и в традиционных и в Web-приложениях?
СМ: Это одна из целей разработки JSF. Мы хотим создать
основную структуру, а уже в ней с помощью IDE и других средств разработки можно
будет создать среду разработки страниц. Многие вендоры средств разработки входят
в экспертную группу JSF. О конкретных планах вендоров лучше спросить у них.
AF: Это действительно хороший вопрос, который немало
тащит за собой. На самом деле обычные и Web-клиенты сильно различаются. Нужно
сказать, что мы видим возможность упростить создание и развертывание обоих типов
клиентов, причем значительная часть back-end приложения может использоваться
обоими типами (проверки, бизнес-логика, подключение к БД и т.п.). Мы думаем над
этим, и заинтересованы в любых пожеланиях разработчиков. Этого не будет в JSF
1.0, но, возможно, это можно будет сделать отдельно.
Q: Прав ли я, считая, что JSF позволит (в дальнейшем)
сохранять состояние на клиенте?
СМ: Вы правы. При планировании масштабируемости в
больших приложениях часто встречается проблема потребности в памяти для
сохранения состояния в сессии, поэтому JSF позволяет реализации сохранять
состояние в запросе (возвращаемов в виде скрытой переменной). Мы уже сделали это
в последней версии эталонной реализации.
Q: Хотелось бы видеть эталонную реализацию с открытым
кодом. Это будет?
СМ: Благодаря недавнему соглашению между Sun и Apache,
разработчики теперь могут создавать open-source JSF-приложения, и даже получить
помощь в прохождении тестов на соответствие спецификации.
Q: Мне кажется, что текущая спецификация JSF нацелена
исключительно на работу с пользовательским вводом, а не на разного сорта
компоненты, упрощающие передачу информации среде JSF и упрощение отрисовки;
например, простые механизмы для раскладки, шрифтов и т.д. Попадают ли такие
компоненты в поле зрения JSF?
СМ: Хороший вопрос. JavaServer Faces, разумеется,
предполагает создание более сложных компонентов, чем простые элементы,
представленные в Early Access. Действительно, сейчас экспертная группа обсуждает
дизайн нескольких таких компонентов. Но, поскольку это очень ранняя версия API,
мы хотели отладить основные API к выпуску EA. Лично я делал прототипы нескольких
интересных сложных компонентов (многострочные таблицы, деревья, панели с
закладками и т.п.). Какие войдут в "стандартный" набор отрисовщиков – все еще
предмет споров.
Q: Поддерживается ли XML в JSF?
СМ: К JavaServer Faces можно обращаться на нескольких
разных уровнях. Во-первых, она может работать как низкоуровневый API,
позволяющий напрямую манипулировать компонентами. Под "компонентом" в этом
случае я имею в виду независимые от отрисовщика характеристики компонента.
Например, компонент "select one" будет содержать список значений (и их меток),
плюс выбранное в текущий момент значение. Рендерер отвечает за вывод этого
компонента на выбранном языке разметки (или в двоичном формате). Рендереры
определяют дополнительные зависимые от них атрибуты. Для нашего компонента "select
one" есть пара способов отображения (в HTML): как выпадающий список (HTML
элемент <select>), или как набор переключателей. Каждому из них должен
соответствовать отдельный отрисовщик, умеющий выводить на экран такого рода
компоненты. Для пользователей JavaServer Pages (JSP) это в общем случае будет
специальный тег для комбинации компонента и поддерживающего его рендерера. В JSF
войдет стандартный RenderKit, отрисовывающий вывод в HTML/4.01. Однако можно
будет прямо подключить другой RenderKit, и выводить все по-другому. <...> Короче
говоря, стандартный RenderKit напрямую не поддерживает XML, но JSF API позволяет
создать такую поддержку.
Q: Как соотносятся JSF и портлеты?
СМ: Как нетрудно догадаться, экспертные группы JSR-127
(JavaServer Faces) и JSR-168 (портлеты) понимают важность совместной работы для
обеспечения взаимодействия этих технологий. Ключевые вопросы (и цели) таковы:
можно ли использовать компоненты JavaServer Faces в портлетах для создания
пользовательского интерфейса? Можно ли использовать компоненты JavaServer Faces
на самом портальном сервере для создания общего стиля страниц? Хотя все это и
выходит за рамки JSR-168 (определяющего только API между портальным сервером и
портлетами), мы хотим сделать это возможным.
Q: Какие требования JSF предъявляет к броузеру?
Компоненты JSF – это JavaScript, апплеты, встраиваемые модули или чисто
серверная абстракция старого доброго HTML?
AF: Архитектура JSF не зависит от клиентских
технологий. И хотя наиболее популярное применение JSF – отрисовка HTML-клиентов
в броузере (с или без JavaScript), технически возможен рендеринг JSF-клиентов
самыми разными путями, хотя бы и с помощью апплетов. Реализация будет включать
поддержку рендеринга классических HTML-клиентов, но мы надеемся на креативность
разработчиков, которые создадут другие виды RenderKit-ов (название класса,
инкапсулирующего кодирование/декодирование UI в выбранной технологии). <...>
Q: Крейг, я посмотрел пример из эталонной реализации,
и заметил, что многие теги и методы для отображения на bean-ы уже сделаны в
Struts. Насколько они перекрываются?
СМ: Представьте себе, это вопрос, который мне часто
задавали на JavaOne US (в марте) и совсем недавно на JavaOne Japan в Йокогаме.
На свете есть много framework-ов для Web-приложений (включая Struts), и все они
начинаются со своего взгляда на взаимодействие компонентов и с того, какой тип
back-end контроллера используется. Экспертная группа, разумеется, учится на их
опыте. Главная цель JSF – стандартизировать API самого нижнего уровня для
разработки компонентов, содействовать разработке большого количества компонентов
и дать возможность производителям средств разработки поддерживать одно API для
разработки компонентов. Что касается, в частности, Struts, это в значительно
означает значительное перекрытие с существующей библиотекой HTML-тегов struts
(так же, как JSTL значительно пересекается с библиотеками bean и logic). Такие
вещи неплохо бы стандартизировать. Пользователям Struts я недавно объявил через
рассылки STRUTS-DEV и STRUTS-USER, что будет создана интегрирующая библиотека
(сейчас готовая на три четверти). Она позволит постранично перевести
пользовательские интерфейсы приложений Struts, использующие теги struts-html, на
использование тегов компонентов Faces – без изменений в бизнес-логике и с
незначительными исправлениями файла struts-config.xml. Должна же быть хоть
какая-то награда за честное следование дизайн-паттернам MVC :-). Что касается
новых Struts-приложений, я рекомендовал бы использовать стандартные теги вместо
тегов Struts, это позволит Struts использовать все сделанные другими сложные
компоненты.
Q: С чего бы людям использовать JSF? Когда не стоит
использовать JSF?<...>
СМ: На самом деле возможности применения и достоинства
JSF зависят от того, кто вы такой и какую роль играете в процессе разработки.
Давайте рассмотрим пару разных вариантов. Если вы дизайнер, больше всего
озабоченный дизайном пользовательского интерфейса, вам пригодится библиотека
готовых тестированных компонентов, представленных иконками в IDE. Тот факт, что
JSF – это стандарт, будет способствовать разработке множества таких компонентов
вместо частных библиотек компонентов от разных вендоров. Если же вы –
разработчик компонентов, пытающийся создавать многократно используемые
компоненты, вам доставит немало расстройства необходимость адаптировать свои
компоненты под все API всех существующих средств. Хорошо было бы писать
компоненты один раз, и затем использовать их во множестве разных средств
разработки, или множестве разных приложений, основанных на разных
Web-framework-ах? JSF сделает это возможным – предполагая, конечно, что эти
framework-и будут поддерживать JSF :-). Если же вы создаете средство разработки
или IDE, вы будете смотреть на это с другой стороны – хлопотно поддерживать
библиотеки компонентов, рассчитанные на использование разных низкоуровневых API,
так что вы постараетесь сфокусироваться на чем-то одном. Это ограничивает число
компонентов, доступных пользователям вашего средства. Но JSF позволит
производителям средств разработки импортировать и встраивать компоненты других
разработчиков. <...>
Q: Хотелось бы знать, как создать дерево "с нуля" и
отрисовать его. Я могу сделать это, написав собственный обработчик вывода, но
это представляется стрельбой из пушки по воробьям. Есть ли какие-то идеи насчет
отрисовки такого дерева с помощью стандартного обработчика вывода? Этот вопрос
приводит еще к одному: какова связь между возвращаемой страницей (outbound tree)
и деревом ответа (response tree) относительно стандартного обработчика вывода?
Что, если приложение само создает дерево ответа и хочет как-нибудь вывести его,
используя существующую JSP-страницу? Дерево ответа может иметь собственную
иерархию компонентов, не ту, что у JSP-страницы. EA-спецификация ничего об этом
не говорит.
СМ: Я уже создал очень примитивный прототип
компонента-дерева:
-
Объект-модель, представляющий граф узлов (веток) (с
названиями, развернутым/свернутым состоянием и т.д.).
-
Сам компонент, знающий, как реагировать на события
раскрытия/закрытия веток.
-
Рендерер, знающий, как вывести результат (для моего
прототипа – просто в HTML, но концептуально можно сделать массу всего, в
зависимости от возможностей броузера). После этого мне удалось объединить все
эти куски в тестовое приложение и использовать их вместе с другими
компонентами. Скорее всего, стандартные версии наших сложных компонентов будут
работать именно по этой схеме. Единственный случай, когда вы можете заменить
отрисовщик – это если вы не хотите использовать RequestDispatcher.forward()
для передачи управления логике, отвечающей за формирование ответа. Например,
если вы уже используете технологию шаблонов (на основе сервлетов), вызываемую
напрямую. И даже в этом случае можно заставить ваш обработчик вывода
отрисовать компонент-дерево.
Q: Будет ли какой-нибудь процесс сертификации на
соответствие JavaServer Faces?
СМ: JavaServer Faces разрабатывается в рамках Java
Community Process (JCP). Кроме прочего, JCP требует создания Technology
Compatibility Kit (TCK), который люди, реализующие wJavaServer Faces, могут
использовать для проверки соответствия реализаций спецификации. Эталонная
спецификация (также требуемая JCP-процессом) должна пройти TCK-тесты до выхода
окончательной спецификации. Кроме того, спецификация также доступна любому
желающему создать собственную реализацию JSF. <...>
Copyright © 1994-2016 ООО "К-Пресс"
Home
Поиск
Издания
Контакты
