The attentive reader will likely have noticed that that we have not taken advantage of all the new capabilities of JSF 2.2 (http://jcp.org/en/jsr/detail?id=344) in our code. The reason for this is that the requirements of the application can be fulfilled without these enhancements. Although JSF 2.2 was a minor release, it did incorporate many improvements into the Standard. The most important changes were referred to as Big Ticket Features. We have already used a couple of them – namely Resource Library Contracts and HTML5 support. This section will outline two of the other major improvements. Though we haven’t used them in our application, these developments are still interesting to know about.
9.1 Faces Flows
We often encounter the concept of the user being guided through a series of pages by a web application for the purpose of fulfilling a task. Page flows of this kind can be found in Wizards, multi-page questionnaires or booking processes. In such cases, the amount and complexity of data to be entered is usually too great for the application to request that the user enters it all on one page. Additionally, the page flow enhances the intelligibility and user acceptance of the application, which in turn leads to a lower error rate and a higher number of users. Up until JSF 2.2, the implementation of such a page flow was not explicitly supported.
With Faces Flows, JSF 2.2 provides a mechanism with which a page flow can be defined as a reusable module for JSF applications. Each page flow is defined by a number of flow nodes and by a flow definition that determines how the flow nodes will be executed when the page flow is run. Here, too, the principle of convention over configuration is adhered to, which enables the creation of a page flow even without explicit configuration. Should a configuration be necessary, it can be accomplished in two ways. The first option is to use the FlowBuilder API to define the page flow programmatically in a class containing the @FlowDefinition annotation from the javax.faces.flow package. Alternatively, the page flow can be established in a configuration file of the name <flow-name>-flow.xml, whereby flow-name represents the unique name of the page flow in the web application.
The flow nodes can be Facelets, method calls, branches in the navigations, calls to other page flows or a return to the calling page flow. When calling a page flow from another page flow, parameters can be passed and returned again when the called page flow has ended.
To enable a bean to assume the role of controller during the page flow, a new scope for CDI beans was introduced. A CDI bean that is annotated with @FlowScoped from the package javax.faces.flow is created at the start of the page flow and destroyed when it has finished. All data stored there are available independently of the flow node for the time that the page flow exists.
Additionally, a new EL object (#{flowScope}) was introduced as a local map in the page flow via which data can be passed from Facelet to Facelet. The map can also be requested via the FacesContext:
facesContext.getApplication().getFlowHandler().getCurrentFlowScope()
All artifacts belonging to a page flow (Facelets, classes, configuration files etc.) are saved in a directory with the name of the page flow (flow-name) and made available either directly in the root directory of the application or as a JAR file in the application’s web archive. This is how the modularization of page flows is achieved.
9.2 Stateless Views
When a user interacts with a view, its state is stored in between view accesses. The state of a view includes the state of its components, validators and converters. For example, the state of a component could be the current selection in a checkbox.
The time it takes to answer a request is generally shorter than the time between two consecutive requests in the same session. If we want to retain the view state between two requests in the main memory, this could – in the case of several users doing the same thing – lead to critical load on the server. For this reason, the view state between two requests will be cached and reloaded in the first step of the next request.
The states of the view can be stored either on the server or the client. On the server, the HTTP session of the underlying Servlet is generally used; in contrast, storing the data in the client uses a hidden INPUT element. While storing the state in the client stresses the bandwidth of the communication in both directions, storing it on the server will place demands on the server’s memory.
While the size of the state of a view was once a weak point in JSF, the introduction of partial state saving in JSF 2.0 was successful in optimizing memory requirements. With partial state saving, the implementation did not save the complete component tree in its current state, but only the changes in relation to the initial state. Restoring the state could then be accomplished using the initial state and the stored changes, resulting in significantly reduced memory demands.
JSF 2.2 then introduced stateless views (tag <f:view> with the boolean attribute transient). For stateless views, the view state between two requests was not stored at all, which saved on memory, bandwidth and computer capacity. In addition, stateless views meant that the view state between consecutive requests did not end up being saved for no reason. Following a request to a view, users generally want to continue working with the same state. For this reason, the use of stateless views makes sense only in use cases for which very few or no successive requests to the same view are expected. One example from our application would be the donation list (Facelet listDonations.xhtml). After the first time it’s accessed, this shows only a table with campaign and a button for exiting the view. We can therefore safely dispense with storing the state of this view.
Discussion
Use the message board below to give the authors your feedback or to discuss this page’s topic with other readers (in English please!). Please don’t expect the authors to answer directly, but they might update the content of this site according to your feedback.