Java Reference
In-Depth Information
The following example demonstrates the
viewAction
facet that will cause the action to be invoked during the
Process Validations phase:
<f:viewAction action="#{viewActionManagedBean.viewActionExample()}"
phase="PROCESS_VALIDATIONS"/>
Faces Flow
The concept of session management has been a difficult feat to tackle since the beginning of web applications.
A
web flow
refers to a grouping of web views that are interrelated and must have the ability to share information with
each view within the flow. Many web frameworks have attempted to tackle this issue by creating different solutions
that would facilitate the sharing of data across multiple views. Oftentimes, a mixture of session variables, request
parameters, and cookies are used as a patchwork solution.
In JSF 2.2, a solution has been adopted for binding multiple JSF views to each other, allowing them to share
information among each other. This solution is called
faces flow
, and it allows a group of interrelated views to belong
to a “flow instance,” and information can be shared across all of the views belonging to that flow instance. Flows
contain separate navigation that pertains to the flow itself, and not the entire application. As such, flows contain their
own configuration, and custom navigation can be defined in an XML format or via code using a builder pattern.
In this section, you will take a brief tour of faces flow technology and learn how to get started using it right away.
However, this section will hardly scratch the surface because entire chapters could be written on the topic, and you
are encouraged to learn about all features of faces flow so that you can decide what works best for your applications.
Defining a Flow
Before a flow can be defined within an application, some configuration must be made. You can designate a flow
by creating a folder structure to encapsulate all nodes belonging to a flow. By convention, a directory that has the
same name as a flow can be used to contain all nodes belonging to that flow. Moreover, the start node for a flow can
optionally be designated as such by naming it the same as the flow (and the enclosing folder). For instance, if your
flow were named
exampleFlow
, then each of the views that belonged to the flow should be placed inside a folder
named
exampleFlow
, which resides at the root of the application web directory. Figure
2-1
shows how a flow directory
structure might look.
Figure 2-1.
Faces flow directory structure
If you need to add custom navigation to your flows, you must decide upon the means by which your flow
configurations will be defined. As mentioned previously, flows can contain their own navigation rules. As such, each
flow can specify a set of navigational rules in some format, be it XML or code. If using XML, the flow configuration
can be placed within the
faces-config.xml
file, or it can be placed within an XML file that has the same name as the
flow, along with a
flow.xml
suffix, also referred to as a flow definition. Placing flow rules in their own separate files
can be handy if your application has more than one flow, because it tends to make maintenance a bit easier. It can
also be handy if you plan to package your flow for inclusion in another application, as described later in this chapter.
