Ajax и JSF, наконец-то присоединившиеся

С другой стороны, атрибут render указывает JSF, какая часть дерева компонентов должна быть визуализирована и заменена на клиенте при возврате ответа.   Для пользователя это та часть браузера, которая волшебным образом обновляется без обновления всей страницы.   Как и выполнить , вы редко хотите, чтобы вся страница отображалась.   В нашем примере мы хотим, чтобы компонент outtext отображался только после завершения запроса.

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

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

<h:form>
<h:outputScript name="jsf.js" library="javax.faces" target="head"/>

<h:panelGrid columns=”1”>
<h:inputText id="myinput" value="#{userBean.name}"
             onkeyup="jsf.ajax.request(this, event, {render: 'outtext'}); return false;"/>

<h:outputText id="outtext" value="#{userBean.name}"!/>

</panelGrid>
</h:form>

Поэтому теперь каждый раз, когда пользователь вводит символ во входной текст, Ajax-запрос будет отправлен на сервер, а когда запрос вернет, будет обработан компонент outtext .   Обратите внимание, что нам не нужно устанавливать атрибут «execute».   Это потому, что значение по умолчанию для execute является @this .

Этот JavaScript API выполняет двойную функцию. Большую часть времени API будет использоваться библиотеками компонентов. Но пользователи могут использовать его для запуска собственных запросов Ajax, как вы уже видели. Эта гибкость означает, что вам больше не нужно выходить за пределы модели JSF, чтобы создавать собственные Ajax.   Например, библиотека ICEFaces может использовать это для реализации своих функций Direct-to-DOM.   Гибкость и желание взаимодействия библиотек компонентов, предоставляемые этим API, являются ключевыми.

Я знаю, что вы говорите, это здорово и все такое, но я действительно не хочу связываться с JavaScript.   Вы не единственный, кто так чувствует.   Вот почему JSF 2 предлагает декларативное решение «из коробки» в виде <f: ajax> , которое скрывает использование этого API. 

<Е: Аякс>

Как я уже упоминал выше, большинство пользователей стандартного JSF 2.0, вероятно, будут использовать тег <f: ajax>, чтобы они не беспокоились о JavaScript и могли по-прежнему иметь точный контроль над поведением своей страницы.   Любой, кто знаком с RichFaces и его тегом <a4j: support> , увидит очевидную корреляцию в поведении.   Фактически, тег поддержки был большим драйвером и источником вдохновения для тега <f: ajax> .   Архитектор RichFaces и член JSF EG Алекс Смирнов сыграли большую роль в определении этого тега и о том, как он должен работать.

Ниже я покажу вам те же примеры, что и выше, но вместо использования JavaScript API мы будем использовать тег <f: ajax> .   Как вы увидите, с помощью этого тега обычно гораздо проще присоединить функциональность Ajax.   Сначала мы рассмотрим пример с командной кнопкой, с поворотом.

<h:form>
<h:panelGrid columns=”1”>

<h:inputText id="myinput" value="Text: #{userBean.name}"/> <h:outputText id="outtext" value="Echo: #{userBean.name}"/>
 
<h:commandButton id="submit" value="submit">
  <f:ajax execute=”@form” render=”outtext”/>
</h:commandButton>

</panelGrid>

</h:form>

Как вы можете видеть, это стало намного чище, а тег <f: ajax> позаботится обо всем тяжелом JavaScript.   В этом примере я использовал ярлык @form, чтобы каждый компонент родительской формы обрабатывался на сервере.   Как и прежде, мы также указываем, что внешний текст должен быть возвращен клиенту.   При нажатии кнопки запрос будет запущен, и страница обновится, как и раньше.

В следующем примере мы уберем кнопку и дублируем второй пример из раздела JavaScript API. 

<h:form>

<h:panelGrid columns=”1”>
<h:inputText id="myinput" value="#{userBean.name}">
   <f:ajax event=”keyup” render=”outtext”/>
</h:inputText>
 
<h:outputText id="outtext" value="#{userBean.name}"!/>

</panelGrid>
</h:form>

Так что же здесь отличается?   Во-первых, нам не нужно устанавливать исполнение, потому что по умолчанию это @this .   Мы также устанавливаем атрибут события для тега.   Это клиентское событие родительского компонента, к которому привязывается поведение Ajax и которое инициирует запрос Ajax.   По умолчанию компоненты ввода вызывают <f: ajax>, когда пользователь меняет значение и покидает поле, но я хотел более отзывчивый пользовательский интерфейс, поэтому я решил использовать keyup .   Также обратите внимание , что вам нужно удалить на перед любым случаем вы хотите использовать.

У тега есть больше уловок в рукаве все же.   Вы можете обернуть тег <f: ajax> вокруг нескольких компонентов и дать поведение Ajax всем дочерним элементам одновременно.   Все дети будут использовать свои настройки по умолчанию и события, если вы не переопределите их специально.   Я продемонстрирую   это на примере из спецификации:

<f:ajax>
   <h:commandButton id=”button1”>
   <h:commandButton id=”button2”>
      <f:ajax event=”mouseover”/>
   </h:commandButton>
</f:ajax>

В этом примере к обеим кнопкам будет применено поведение Ajax по умолчанию.   В случае commandButton это будет при нажатии.   Однако только компонент button2 также будет запускать Ajax при наведении курсора мыши .   Это может быть полезно, когда вы хотите применить такое же поведение к группе компонентов, не вводя <f: ajax> для каждого тега.

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

Отлично, это здесь!   Теперь, как это работает?

В JSF 2 в жизненном цикле JSF появилась информация о запросе Ajax.   Большая часть этого понимания — PartialViewContext и функциональность посетителя дерева.   PartialViewContext отвечает за захват состояния, связанного с Ajax-запросом.   Это включает в себя то, что должно быть обработано на сервере, и то, что должно быть отображено на странице.   Функциональность посетителя дерева — это новый метод, visitTree () , в классе UIComponent .   Метод visitTree () позволяет легко перемещаться по подмножеству дерева компонентов в контексте текущего запроса. 

После того, как они были созданы, парадигма частичного обновления страницы идеально подходит для JSF, поскольку на сервере есть представление того, что отображается на экране. Страница может быть обновлена, а JSF может оставаться в цикле.   Большая часть добавления этой поддержки включала использование существующего механизма обработки событий в JSF и расширение его до браузера для запросов на основе Ajax.

У JSF всегда была модель программирования, основанная на событиях, но более ранние версии имели недостаток в том, что предполагалось, что каждое событие должно обрабатываться сервером посредством традиционной операции POST. JSF 2.0 представил обновленный подход, который полностью осознает, что в уравнении есть две стороны, что не все события будут обрабатываться сервером и что может использоваться более эффективный метод связи между клиентом и сервером (Ajax), а не традиционный пост. Так что он умнее, экономнее и даже больше похож на фреймворки с графическим интерфейсом (на самом деле, они вызывают удаленные сервисы).

Частичная обработка дерева

Когда вы определяете значение execute в приведенных выше примерах, вы сообщаете JSF, какие сегменты дерева компонентов на стороне сервера должны проходить через жизненный цикл или фазы запроса JSF.   Дерево компонентов JSF предлагает сильную пригодность для обработки Ajax-запроса, подобного этому, потому что компоненты могут быть однозначно идентифицированы.   Это позволяет легко идентифицировать и обрабатывать отдельный компонент или целое поддерево.

Поэтому, когда вы устанавливаете параметр execute следующим образом:

<f:ajax execute=”@form” .../>

И API JavaScript на стороне клиента, и жизненный цикл на стороне сервера знают, что только компоненты в родительской форме должны пройти проверку, преобразование и   обновить модель.   Когда действия вызваны, значения, выраженные таким образом, будут там в ожидании. 

Частичные обновления страницы

Настоящая магия Ajax и заметный эффект, который в конечном итоге видят конечные пользователи, заключается в том, что части их браузера внезапно обновляются без перезагрузки всей страницы.   JSF 2.0 выполняет это очень похоже на то, что RichFaces делал в JSF 1.2 дня.   Как и атрибут execute, атрибут render указывает JSF, какие сегменты дерева компонентов JSF необходимо обработать (обработать) на этапе ответа визуализации.

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

Оказавшись на клиенте, JavaScript вступает во владение и находит соответствующие элементы DOM, которые обычно называются так же, как их близнецы на стороне сервера.   Затем код на стороне клиента отсекает элементы DOM, включая их дочерние элементы, и заменяет их новым содержимым из ответа.

Компоненты играют хорошо вместе

В этой статье я говорил о совместимости между наборами компонентов.   В конечном итоге это будет настоящий урожай JSF 2.0.   Общим ядром JavaScript Ajax API является большой аспект этого.   Если все библиотеки компонентов могут договориться и использовать одноядерный API, мы проделаем долгий путь к истинному взаимодействию.

Различные команды библиотек компонентов уже начали обсуждение того, как реализовать, протестировать и продемонстрировать эту возможность.   Мы стремимся к тому, чтобы разные библиотеки работали вместе на примере приложения Возможно, мы извлекаем таблицу данных из RichFaces, дерево из IceFaces, меню из ADF и сворачивающуюся панель из PrimeFaces. Этот тип приложения действительно будет делать несколько вещей. С одной стороны, это послужит доказательством и примером для разработчиков, что библиотеки компонентов JSF 2.0 действительно могут работать вместе. С другой стороны, это поможет всем нам избавиться от проблем и проблем, с которыми разработчики столкнутся при разработке спецификации.

Этот второй момент не следует недооценивать, и вот почему.   Найденные таким образом элементы представляют области реализации, которые могут привести к тому, что библиотеки компонентов не функционируют вместе, или указывают области в спецификации, которые нуждаются в большем определении.   Для разработчика JSF это означает, что библиотеки компонентов будут брать на себя большую часть риска разработки JSF для вас.   Когда эта работа будет завершена, и различные проекты выпустят свои интегрированные наборы компонентов JSF 2.0, разработчики JSF получат одну из крупнейших и наиболее продвинутых библиотек компонентов, доступных в веб-разработке.

Заворачивать

Если вы думаете, что все это аккуратно, подождите, пока вы не услышите о структуре поведения, на которой построен тег <f: ajax> .   Здесь работает основная концепция, которая проявляется в JSF 2.0 как новая концепция поведения компонентов.   Интересная вещь в поведении состоит в том, что они обобщают процесс, посредством которого функциональные возможности, как серверные, так и клиентские, могут быть присоединены к компонентам, а не только функциональные возможности, связанные с Ajax. Как только компонент может иметь привязанное к нему поведение, открывается дверь для присоединения всех видов новых поведений.   В следующей статье этой серии будет подробно рассмотрен механизм поведения.   В том числе, как создать свое собственное поведение, и некоторые возможные варианты использования для этого. 

Эта структура поведения является примером одной из точек расширения, которые были включены в спецификацию JSF 2.0.   Его предшественник, JSF 1.2, также позволял таким средам, как Facelets, Seam и RichFaces, расширять и улучшать функциональность.   Возможность поддержки расширений имеет решающее значение для успеха любой технологии.   Он позволяет усовершенствованиям пользователей по мере изменения технологий и требований — как они всегда делают, и JSF 2 имеет все возможности для поддержки этого роста.