Свободная навигация в JSF 2

В этой статье, третьей из серии, посвященной функциям JavaServer Faces (JSF) 2.0, предоставленной Red Hat, или в которой Red Hat активно участвовал, вы узнаете, что обход в приложении JSF 2 намного проще и требует меньше ввода текста. Благодаря улучшенной поддержке запросов GET и возможности закладок, о которых говорилось в предыдущей статье, JSF 2 стала более гибкой. Но не за счет хорошего дизайна. JSF больше не нужно вторгаться в ваши бизнес-объекты, требуя методы действий для возврата результатов навигации, но вместо этого может отражать состояние системы при выборе варианта навигации. Эта статья должна дать вам оценку того, насколько интеллектуальной стала навигационная система в JSF 2.

Прочитайте другие части этой серии статей:

Часть 1 —
JSF 2: Другой
путь к стандартизации в Seam
Часть 2 —
JSF 2 GETs Закладочные URL-адреса 

Часть 3 —
Свободная навигация в JSF 2

Часть 4 —
Ajax и JSF, присоединились наконец

Часть 5 —
Введение Поведение клиента JSF 2

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

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

Даже с этими новыми опциями невозможно сказать, какие требования может предъявлять ваше приложение к навигации. Таким образом, в JSF 2 вы можете, наконец, запрашивать и изменять варианты навигации; В JSF 2 был представлен новый API, который предоставляет набор правил навигации. Прежде чем мы перейдем к настройкам, давайте выясним, как эти новые варианты делают навигационную систему более гибкой и помогают подготовить следующий шаг пользователя. Надеюсь, вам не понадобятся эти настройки в конце концов.

Гибкие возможности навигации

Декларативная навигационная модель в JSF была отходом от явного выбора навигации «вперед» действием в Struts. Навигационные переходы в JSF, которые сопоставляются на основе текущего идентификатора представления, логического результата и / или сигнатуры выражения действия, описываются в дескрипторе JSF (face-config.xml) с использованием правил на основе XML. Соответствующий переход указывает на следующее представление для рендеринга и должен ли перенаправление на стороне клиента продолжать рендеринг. Вот типичный пример:

<navigation-rule>
   <from-view-id>/guess.xhtml</from-view-id>
   <navigation-case>
      <from-action>#{numberGuessGame.guess}</from-action>
      <from-outcome>correct</from-outcome>
      <to-view-id>/gameover.xhtml</to-view-id>
   </navigation-case>
</navigation-rule>

Хотя навигационная модель JSF более четкая и, возможно, более гибкая, чем в Struts, остаются две фундаментальные проблемы. Во-первых, метод действия по-прежнему требуется для возврата навигационной директивы. Директива просто оказывается более «нейтральным» строковым результатом, а не явным типом (т.
Е. ActionForward ), но связь такая же тесная, и вы теряете безопасность типов в процессе, так действительно ли это улучшение? Другая проблема заключается в том, что вы должны определить вариант навигации, соответствующий этому результату, даже в самых простых случаях, которые могут быть очень утомительными. Таким образом, вы не можете утверждать, что навигационная модель менее навязчива или более удобна. Это просто застряло где-то посередине.

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

Неявная навигация

JSF будет публиковать форму обратно в текущее представление (используя метод POST HTTP) всякий раз, когда пользователь выполняет действие, такое как нажатие кнопки команды (отсюда и термин «обратная передача»). Раньше единственный способ заставить JSF перейти в другое представление после вызова действия (т. Е. После фазы приложения Invoke) — это определить случай навигации в файле face-config.xml. Случаи навигации сопоставляются на основе EL-сигнатуры вызванного метода действия и возвращаемого значения метода, преобразованного в строку (логический результат). Чтобы привести пример, предположим, что пользователь нажимает кнопку, определенную следующим образом:

<h:commandButton action="#{commandHandler.preview}" value="Preview"/>

Метод
preview () в компоненте с именем
commandHandler возвращает значение, указывающее результат обработки:

public String preview() {
   // tidy, translate and/or validate comment
   return "success";
}

Эти два критерия объединены в навигационном случае, который определяет, какое представление должно быть отображено следующим.

<navigation-rule>
   <from-view-id>/entry.xhtml</from-view-id>
   <navigation-case>
      <from-action>#{commentHandler.preview}</from-action>
      <from-outcome>success</from-outcome>
      <to-view-id>/previewComment.xhtml</to-view-id>
   </navigation-case>
</navigation-rule>

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

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

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

1. Обнаружить наличие? персонаж в логическом исходе
   
   1. Если есть, захватите параметры строки запроса, которые следуют за ним? характер
   2. Специальный параметр строки запроса Face-Redirect = True указывает, что эта навигация должна быть выполнена с использованием перенаправления на стороне клиента
2. Если логический результат не заканчивается расширением файла, добавьте расширение файла текущего идентификатора представления (например, .xhtml)
3. Если логический результат не начинается с /, добавьте местоположение текущего идентификатора представления (например, /, / admin / и т. Д.)
4. Попытка найти шаблон для идентификатора представления
   
   1. Если шаблон найден, создайте виртуальный случай навигации, который нацелен на идентификатор разрешенного представления.
   2. Если шаблон не найден, пропустите неявную навигацию
5. Выполнить навигационный кейс
   
   1. Если случай навигации не является перенаправлением, создайте и визуализируйте целевое представление в том же запросе
   2. Если в качестве случая навигации используется перенаправление, создайте URL-адрес перенаправления, добавив параметры строки запроса, полученные ранее, и перенаправьте на него

Неявная навигация может использоваться везде, где интерпретируется логический результат. Это включает:

• Возвращаемое значение метода действия
• Атрибут action компонента UICommand (например, <h: commandButton action = «/ records.xhtml» …> )
• Атрибут исхода UIOutcomeTarget (например, <h: link result = «/ records.xhtml» …> )
• Метод handleNavigation () API NavigationHandler

Вот пример перехода к представлению предварительного просмотра, переведенному в неявную навигацию. Возвращаемое значение автоматически украшается начальным / и конечным .xhtml.

public String preview() {
   // tidy, translate and/or validate comment
   return "previewComment";
}

Представление /previewComment.xhtml будет отображено в том же запросе. Если вы хотите перенаправить сначала, добавьте следующий флаг в строку запроса возвращаемого значения:

public String preview() {
   // tidy, translate and/or validate comment
   return "previewComment?faces-redirect=true";
}

Вы можете выполнить любой сценарий навигации, используя неявную навигацию, которую вы можете сделать сегодня, с формальным случаем навигации, определенным в Face-config.xml Неявная навигация спроектирована как случай сбоя (после ознакомления с правилами явной навигации). Если происходит сбой (т. Е. Шаблон не может быть найден ), и JSF 2
ProjectStage устанавливается на разработку, автоматически генерируется FacesMessage, чтобы предупредить разработчика о возможной ошибке программирования.

<navigation-case>
   <from-action>#{registration.register}</from-action>
   <if>#{currentUser.registered}</if>
   <to-view-id>/account.xhtml</to-view-id>
   <redirect/>
</navigation-case>

<navigation-case>
   <from-action>#{identity.login}</from-action>
   <if>#{currentUser.admin}</if>
   <to-view-id>/admin/home.xhtml</to-view-id>
   <redirect/>
</navigation-case>
<navigation-case>
   <from-action>#{identity.login}</from-action>
   <if>#{currentUser.vendor}</if>
   <to-view-id>/vendor/home.xhtml</to-view-id>
   <redirect/>
</navigation-case>
<navigation-case>
   <from-action>#{identity.login}</from-action>
   <if>#{currentUser.client}</if>
   <to-view-id>/client/home.xhtml</to-view-id>
   <redirect/>
</navigation-case>

<navigation-case>
   <from-action>#{identity.logout}</from-action>
   <if>#{true}</if>
   <to-view-id>/home.xhtml</to-view-id>
   <redirect/>
</navigation-case>

<navigation-case>
   <from-action>#{identity.login}</from-action>
   <to-view-id>#{navigationHelper.userHomeViewId}</to-view-id>
   <redirect/>
</navigation-case>

<h:link outcome="home" value="Home"/>

<navigation-rule>
   <from-view-id>*</from-view-id>
   <navigation-case>
      <from-outcome>home</from-outcome>
      <to-view-id>/home.xhtml</to-view-id>
   </navigation-case>
</navigation-rule>

<a href="/app/home.jsf">Home</a>

<h:link outcome="entry?id=#{blog.entryId}" value="Permalink"/

<h:link outcome="entry" value="Permalink">
   <f:param name="id" value="#{blog.entryId}"/>
</h:link>

<h:link outcome="permalink" value="Permalink"/>

<navigation-case>
   <from-outcome>permalink</from-outcome>
   <to-view-id>/entry.xhtml?id=#{blog.entryId}</to-view-id>
</navigation-case>

<navigation-case>
   <from-action>#{commentHandler.post}</from-action>
   <to-view-id>/entry.xhtml</to-view-id>
   <redirect>
      <view-param>
         <param-name>id</param-name>
         <param-value>#{blog.entryId}</param-value>
      </view-param>
   </redirect>
</navigation-case>

NavigationCase case = navigationHandler.getNavigationCase(
   facesContext, "#{commandBoard.post}", "success");

Map<String, Set<NavigationCase>> cases =
   navigationHandler.getNavigationCases();

ConfigurableNavigationHandler nh =
   (ConfigurableNavigationHandler) FacesContext.getCurrentInstance()
   .getApplication().getNavigationHandler();