JSF 2 ПОЛУЧАЕТ закладки URL

JSR-314: JavaServer Faces (JSF) 2.0 демонстрирует сильную эволюцию инфраструктуры JSF, основанную на фактических стандартах, появившихся в сообществе JSF и продуктах участвующих вендоров. В этой статье, второй статье из серии, посвященной функциям JSF 2.0, предоставленной Red Hat, или в которой Red Hat активно участвовал, рассматриваются новые функции, обеспечивающие формализованную поддержку GET в среде, традиционно основанной на запросах POST. Основными строительными блоками этой поддержки являются параметры представления и пара компонентов пользовательского интерфейса, которые создают закладки с закладками. Обе функции инкубируются в Seam и, следовательно, должны быть знакомы любому разработчику Seam. Они также являются особенностями, за которые страстно отстаивает сообщество JSF.

Примечание автора: большое спасибо Питу Мьюру , который сыграл ключевую роль в качестве технического редактора этой серии.

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

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

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

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

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

Каждый сеанс пользователя должен где-то начинаться. JSF был разработан с расчетом на то, что пользователь всегда начинает с представления запуска. Это представление фиксирует начальное состояние и позволяет пользователю указать, какое действие вызывать, вызывая событие пользовательского интерфейса, например нажатие кнопки. Например, для просмотра ипотечного кредита пользователь может ввести свой идентификатор в текстовое поле и затем нажать кнопку «Поиск».

Предположение, что этот сценарий является нормой, является неожиданным, поскольку оно упускает из виду тот факт, что сеть была основана на концепции гиперссылки. Гиперссылка указывает на ресурс (URI), который может уже содержать исходное состояние и намерение, например, для просмотра сводной информации об ипотечном кредите. В этом случае нет необходимости беспокоить пользователя представлением запуска.

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

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

Мы начнем с изучения параметров представления, как они определены и как они работают в жизненном цикле JSF. Затем вы узнаете, как они работают в тандеме с новыми компонентами, создающими гиперссылки, и обработчиком навигации, обеспечивающим «закладочную» поддержку JSF.

Представляем параметры просмотра

Документация по API описывает параметр представления, представленный классом компонента javax.faces.component.UIViewParameter , как декларативную привязку между параметром запроса и свойством модели. Привязка к свойству модели выражается с использованием выражения значения EL (например, # {blog.entryId} ). Если выражение опущено, параметр запроса связывается с переменной области запроса с тем же именем.

Вот простой пример параметра представления, который отображает значение параметра запроса с именем id на свойство стиля JavaBean с именем entryId в управляемом компоненте с именем blog .

<f:viewParam name="id" value="#{blog.entryId}"/>

Предполагая, что
свойство entryId в управляемом компоненте блога имеет тип long, для свойства будет присвоено значение 9 при запросе следующего URL-адреса:

http: //domain/blog/entry.jsf? Id = 9 

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

Прежде чем идти дальше, важно отметить, что параметры представления доступны только при использовании нового языка декларации представления (VDL), стандартизированной версии Facelets. Основная причина в том, что EG JSR-314 согласился с тем, что не следует создавать новые функции для поддержки JSP, поскольку он не рекомендуется использовать как обработчик представления в JSF 2.

Возможно, вы думаете …

Разве это уже не возможно?

Если вы опытный разработчик JSF, вы, возможно, знаете, что уже можно сопоставить значение параметра запроса со свойством модели. Назначение объявляется путем ссылки на элемент карты # {param} в элементе <managed-property> объявления управляемого компонента. Например, вы могли бы альтернативно сопоставить параметр запроса id с управляемым bean-компонентом блога в face-config.xml следующим образом:

 <managed-bean>
   <managed-bean-name>blog</managed-bean-name>
   <managed-bean-class>com.acme.Blog</managed-bean-class>
   <managed-property>
      <property-name>entryId</property-name>
      <value>#{param['id']}</value>
   </managed-property>
</managed-bean>

На этом сходство заканчивается. Параметры просмотра выходят за рамки этого простого назначения, предоставляя:

• Детализация, ориентированная на представление (отображение свойств в определении управляемого компонента является глобальным для приложения)
• Пользовательские конвертеры и / или валидаторы (вместе с сообщениями об ошибках)
• Би-Направленность

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

Достаточно сказать, что хотя отображение свойств в определении управляемого компонента работает, оно довольно анемично. Параметры просмотра намного более адекватны и надежны в сравнении. Что касается темы в этой статье, параметры представления являются ключом к обеспечению поддержки закладок в JSF. А поскольку закладки связаны с конкретными представлениями, то и параметры просмотра должны.

Это все в поле зрения

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

Фасет метаданных представления

Параметры представления предоставляют информацию о том, как должны обрабатываться параметры запроса, когда представление запрашивается или связывается с ним. Параметры вида не отображаются сами. Поэтому мы говорим, что они являются частью метамодели представления и описаны с использованием метаданных. Итак, вопрос в том, «Где должны жить эти метаданные?»

Оказывается, представление JSF, представленное в корне классом компонента javax.faces.component.UIViewRoot , уже содержит некоторые метаданные. В настоящее время эти метаданные состоят из строковых значений для определения параметров, таких как языковой стандарт, набор визуализации и тип содержимого представления, и выражений методов, которые обозначают наблюдатели фазы для конкретного вида. Например:

<f:view locale="en_US" afterPhase="#{myBean.afterPhaseListener}">
   ...
</f:view>

Хотя значения могут быть назначены этим свойствам метаданных явно в коде Java, чаще они назначаются декларативно с использованием соответствующих атрибутов
тега компонента <f: view> . Но ни
UIViewRoot, ни его компонентный тег
<f: view> не могут вместить сложные метаданные, то есть метаданные, которые не могут быть описаны одним атрибутом. Это были фаска вида метаданных приходит.
Фаска вида метаданных является зарезервированным аспектом
UIViewRoot , названный
javax_faces_metadata

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

<f:view>
   <f:facet name="javax_faces_metadata">
      ...
   </f:facet>
   ...
</f:view>

<f:view>
   <f:metadata>
      ...
   </f:metadata>
   ...
</f:view>

<f:viewParam name="id" value="#{blog.entryId}">
   <f:validateLongRange minimum="1"/>
</f:viewParam>

String viewId = "/your_view_id.xhtml"
FacesContext ctx = FacesContext.getCurrentInstance();
ViewDeclarationLanguage vdl = ctx.getApplication().getViewHandler()
   .getViewDeclarationLanguage(ctx, viewId);
ViewMetadata viewMetadata = vdl.getViewMetadata(ctx, viewId);
UIViewRoot viewRoot = viewMetadata.createMetadataView(ctx);
UIComponent metadataFacet = viewRoot.getFacet(UIViewRoot.METADATA_FACET_NAME);

<f:view>
   <f:metadata>
      <ui:include src="WEB-INF/fragments/common_view_metadata.xhtml"/>
      ...
   </f:metadata>
   ...
</f:view>

<h2>#{blog.blogEntry.title}</h2>
<p>#{blog.blogEntry.content}</p>

@ManagedBean(name = "blog")
public class Blog {
   private Long entryId;
   private BlogEntry blogEntry;

   public Long getEntryId() { return entryId; }
   public void setEntryId(Long entryId) { this.entryId = entryId; }

   public BlogEntry getBlogEntry() {
      if (blogEntry == null) {
         blogEntry = blogRepository.findEntry(entryId);
      }

      return blogEntry;
   }
}

<f:metadata>
   <f:viewParam name="id" value="#{blog.entryId}" required="true" requiredMessage="No entry specified.">
      <f:validateLongRange minimum="1"/>
   </f:viewParam>
   ...
</f:metadata>

<h:messages globalOnly="true"/>

<f:metadata>
   ...
   <f:event type="preRenderView" listener="#{blog.loadEntry}"/>
</f:metadata>

public void loadEntry() {
   blogEntry = blogRepository.findEntry(entryId);
}

<c:if test="#{blog.blogEntry eq null}">
   The blog entry you requested does not exist.
</c:if>

public void loadEntry() {
   try {
      blogEntry = blogRepository.findEntry(entryId);
   } catch (NoSuchEntryException e) {
      FacesContext ctx = FacesContext.getCurrentInstance();
      ctx.getApplication().getNavigationHandler()
         .handleNavigation(ctx, "#{blog.loadEntry}", "invalid");
   }
}

public void loadEntry() {
   FacesContext ctx = FacesContext.getCurrentInstance();
   if (ctx.isValidationFailed()) {
      ctx.getApplication().getNavigationHandler()
         .handleNavigation(ctx, "#{blog.loadEntry}", "invalid");
      return;
   }

   // load entry
}

<f:metadata>
   <f:viewParam name="after" value="#{blog.afterDateFiler}">
      <f:convertDateTime type="date" pattern="yyyy-MM-dd"/>
   </f:viewParam>
   <f:viewParam name="before" value="#{blog.beforeDateFiler}">
      <f:convertDateTime type="date" pattern="yyyy-MM-dd"/>
   </f:viewParam>
   <f:event type="preRenderView" listener="#{blog.loadEntries}"/>
</f:metadata>

<h:form>
   <h:inputText value="#{comment.name}" required="true"/>
   <h:inputTextarea value="#{comment.text}" required="true"/>
   <h:commandButton action="#{commentHandler.post}" value="Post"/>
</h:form>

FacesContext.getCurrentInstance().getExternalContext().redirect("/entry.jsf?id=" + blog.getEntryId());

<navigation-rule>
   <from-view-id>/entry.xhtml</from-view-id>
   <navigation-case>
      <from-action>#{commentHandler.post}</from-action>
      <to-view-id>#{view.viewId}</to-view-id>
      <redirect include-view-params="true"/>
   </navigation-case>
</navigation-rule>

<h:link outcome="/entry.xhtml" includeViewParams="true" value="Permalink"/>

<a href="/blog/entry.jsf?id=9">Permalink</a>

<h:link includeViewParams="true" value="Permalink"/>

<h:button includeViewParams="true" value="Permalink"/>

<button onclick="window.location.href="/blog/entry.jsf?id=9";">Permalink</button>

<f:metadata>
   <f:viewParam name="query" value="#{blog.searchString}"/>
   <f:viewParam name="category" value="#{blog.category}"/>
   <f:viewParam name="page" value="#{blog.page}"/>
</f:metadata>

<h:link includeViewParams="true" value="Refresh query"/>

<a href="/blog/entries.jsf?category=JSF&query=features&page=2">Refresh</a>

<h:link includeViewParams="true" value="Previous">
   <f:param name="page" value="#{blog.page - 1}"/>
</h:link>

<ui:repeat var="_entry" value="#{blog.entries}">
   <h2>#{_entry.title}</h2>
   <p>#{_entry.excerpt}</p>
   <p>
      <h:link outcome="/entry.xhtml" includeViewParams="true" value="View entry">
         <f:param name="id" value="#{_entry.id}"/>
      </h:link>
   </p>
</ui:repeat>

<ui:composition xmlns="http://www.w3.org/1999/xhtml"
   xmlns:ui="http://java.sun.com/jsf/facelets"
   xmlns:f="http://java.sun.com/jsf/core">
   <f:viewParam name="page" value="#{blog.page}"/>
   <f:viewParam name="query" value="#{blog.searchString}"/>
   <f:viewParam name="category" value="#{blog.category}"/>
</ui:composition>

<f:view>
   <f:metadata>
      <ui:include src="/WEB-INF/fragments/common_view_params.xhtml"/>
      <f:viewParam name="id" value="#{blog.entryId}"/>
      ...
   </f:metadata>
</f:view>