JSF 2.0 - Bookmarability/View Parameters
Monday May 18, 2009
This seems to be one of the top features users have been requesting for JSF 2.0. For those of you not reading the specification revisions as it has been published, the feature is available.
Bookmarkability is achieved using two new components:
- h:link
- h:button
So, let's start with a simple example using one of these new components with implicit navigation. Please note that the following examples assume that the FacesServlet is mapped to '*.xhtml'.
<h:link outcome="viewEntry" value="Link">In the example above, outcome, again, is the result of the navigation. In this case, since we're assuming no navigation rules have been defined in the faces-config.xml, we're navigating to viewEntry.xhtml. The f:param tag is adding a query parameter to the generated link. When the component is rendered, the end result is something like:
<f:param name="entryName" value="#{someBean.entry}"/>
</h:link>
<a href="http://localhost:8080/myapp/viewEntry.xhtml?entryName=entry1">Link</a>The same can be achieved using navigation rules defined in the faces-config.xml. For example:
<navigation-rule>Then reference the navigation outcome in one of the new components:
<from-view-id>/page1.xhtml</from-view-id>
<navigation-case>
<from-outcome>redirectOutcome</from-outcome>
<to-view-id>/page2.xhtml</to-view-id>
<redirect>
<view-param>
<name>entryName</name>
<value>#{someBean.value}</value>
</view-param>
</redirect>
</navigation-case>
</navigation-rule>
<h:link outcome="redirectOutcome" value="Link" />which generates:
<a href="http://localhost:8080/myapp/page2.xhtml?entryName=entry1">Link</a>Now, there's a third source of parameters that has been introduced in JSF 2.0 called 'View Parameters'. These parameters are specified as metadata to the page and can be included in the generated URLs. There's a lot more to view parameters than what is about to be shown. I'll go more into that later on in this entry.
Here's a simple example of a View Parameter (assume this is defined within somepage.xhtml):
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"If the developer sets the 'includeViewParams' attribute on h:link or h:button or the include-view-params attribute on the redirect element of a navigation-case to true, then the UIViewParameters will be a part of the generated URL.
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:c="http://java.sun.com/jsp/jstl/core">
<head><title>somepage</title></head>
<body>
<f:metadata>
<f:viewParam id="id" name="viewParam" value="#{someBean.id}" />
</f:metadata>
.
.
</body>
</html>
So, building off of the metadata example above, consider the following h:link within another view:
<h:link outcome="sompage.xhtml" value="Link">The generated URL would look like:
<f:param name="componentParam" value="component"/>
</h:link>
<a href="http://localhost:8080/myapp/somepage.xhtml?componentParam=component&viewParam=view">Link</a>Keep in mind that the view parameters that are included in the generated URL will be those of of the view being navigated to.
It's also important to note that there is an order of precedence for adding the parameters from the different sources. This order is essentially, component, navigation-case parameters, followed by view parameters. This means that if a component specifies a parameter via f:param that has the same name as that in a navigation-case or in the view metadata, then the parameter value from the navigation-case or view metadata will not be included in the query string.
Now, getting back to view parameters, there's some other details I'd like to share. In 1.2, the typical GET lifecycle would result in the restore view phase being invoked immediately followed by render response. This is still true in 2.0 *except* when the view being processed has view parameters. In this case, the view parameters are processed using the standard post-back processing lifecycle (i.e. apply request values, process validations, update model, invoke application, then render response). Processing view parameters in this fashion allows developers to attach converters and validators to the view parameters to enforce the integrity of the parameter data being passed to the view. For example:
<f:metadata>
<f:viewParam id="id" name="id" value="#{newsReader.selectedStoryId}"
required="true"
requiredMessage="You did not specify an id. (The id parameter is missing)"
converterMessage="Invalid id. (The id parameter is not a number)"
validatorMessage="Invalid id. (The id parameter is not a positive number)">
<f:validateLongRange minimum="1"/>
</f:viewParam>
</f:metadata>
Lastly, developers need not restrict their usage of f:metadata to view parameters only. Facelets templating features and view events (i.e. f:event) can also be specified. One useage restriction of f:metadata needs to be kept in mind though - it must be defined within the view and not within a template. If this restriction isn't observed, the content within f:metadata will not be processed.
That should cover the basics for now. Please download the Mojarra 2.0.0 nightly and give this feature a shot. Feel free to ask questions on the GlassFish Webtier forums, and if you think you found an issue, please let us know about it.
Like this post?
|
|
|
|
|
|
|
|
Thanks..
This is good..
Those features seams to be great, but I missed som...
This is one of the most wanted feature after EzCom...
This is still only a partial solution, but it...
This is the feature what I waiting for. My questi...
thanks
Really those new features from JSF 2 are good. Alt...