Inside JSF 2.0's Ajax and HTTP GET Support

Unlike previous releases of JavaServer Faces (JSF), JSF 2.0 supports HTTP GET requests and full Ajax integration. JSF 1.x releases sent all server requests using HTTP POST (hence, no support for GET requests) and offered virtually no support for Ajax integration. With support for these techniques, this newest version of the Java component UI framework enables developers to build truly dynamic web pages simply and easily.

At the highest level, JSF technology provides an API for creating, managing, and handling UI components and a tag library for using components within a web page. The JSF 2.0 release simplifies the web developer's life by providing the following:

Reusable UI components for easy authoring of web pages

Well defined and simple transfer of application data to and from the UI

Easy state management across server requests

Simplified event handling model

Easy creation of custom UI components

In this article, we drill down into JSF 2.0's support for GET requests and Ajax integration, as well as the productive features that this support makes possible. For demonstration, we refer to aspects of a simple application throughout the article. The demo application is an online quiz that allows a registered user to answer five simple questions that test his or her general knowledge. Towards the end of the quiz, the application displays the score.

Using GET Requests in JSF 2.0

To support GET requests, JSF 2.0 introduced the concept of View Parameters. View Parameters provide a way to attach query parameters to URLs. You use the tag <f:viewParam> to specify the query parameters.

Take this code for example:

<f:metadata> <f:viewParam name="previousScore" value="#{recordBean.oldScore}" /> </f:metadata>

In this example, the value of the parameter previousScore will be automatically picked up and pushed into the property oldScore of the recordBean . So, when a request like this comes for a URL:

displayData.jspx?previousScore=10

The value of the bean property oldScore will be set to 10 when the request is processed, which avoids manually setting the value or using a listener. Another interesting point to notice is that like any other component the <f:viewParam> tag supports conversion and validation. Hence, there is no need for separate conversion/validation logic.

Table 1 lists the new tags in JSF 2.0 related to support for the GET request.

Figure 1. New Tags Related to GET Requests



Tag Description h:button Renders a button that generates a GET request without any handcoding of URLs h:link Renders a link that generates a GET request without any handcoding of URLs h:outputStylesheet Refers to a CSS resource h:outputScript Refers to a JavaScript resource f:event Registers a specification-defined or a user-defined event f:ajax Enables associated component(s) to make Ajax calls f:metadata Declares the metadata facet for this view f:viewParam Used in <f:metadata> to define a view parameter that associates a request parameter to a model property f:validateBean Delegates the validation of the local value to the Bean Validation API f:validateRegex Uses the pattern attribute to validate the wrapping component f:validateRequired Ensures the presence of a value

Bookmarking Support

Because all JSF 1.x interactions with the server use only HTTP POST requests, those JSF versions don't support bookmarking pages in a web application. Even though some tags supported the construction of URLs, it was a manual process with no support for dynamic URL generation. JSF 2.0's support for HTTP GET requests provides the bookmarking capability with the help of new renderer kits.

A new UI component UIOutcomeTarget provides properties that you can use to produce a hyperlink at render time. The component allows bookmarking pages for a button or a link. The two HTML tags that support bookmarking are h:link and h:button . Both generate URLs based on the outcome property of the component, so that the author of the page no longer has to hard code the destination URL. These components use the JSF navigation model to decide the appropriate destination.

Take the following code for example:

<h:link outcome="login" value="LoginPage" > <f:param name="Login" value="#{loginBean.uname }" /> </h:link>

This bookmarking feature provides an option for pre-emptive navigation (i.e., the navigation is decided at the render response time before the user has activated the component). This pre-emptive navigation is used to convert the logical outcome of the tag into a physical destination. At render time, the navigation system is consulted to map the outcome to a target view ID, which is then transparently converted into the destination URL. This frees the page author from having to worry about manual URL construction.Page 1 of 2