HTML and CSS Reference
In-Depth Information
private String contract = "basic";
public String getContract() {
return contract;
public void setContract(String contract) {
this.contract = contract;
Listing 5-16 could be extended to pick the selected contract from a cookie or from the database so that the user
would not have to select the contract to apply every time he uses the application.
The method to use for mapping contracts to views depends on your application requirements. You can mix the
two methods to achieve maximum flexibility.
Faces Flows
Since the introduction of JavaServer Faces, a consistent complaint by developers has been the lack of support for a
scope that covers a user flow such as a wizard and multistep sign-up form. In JSF 2.0 the @ViewScope annotation was
introduced to support variable persistence while staying in the same view. @ConversationScoped was introduced
for CDI (Component Dependency Injection) beans in JSF 2.0, and by injecting the javax.enterprise.context.
Conversation interface into a managed bean it was possible to start and end long-running conversations. With
@ViewScope and @ConversationScoped scopes, you can implement multistep sign-up forms and wizards, but once
implemented you find that the final product is rather disintegrated and not easy to reuse. Faces flows deals with these
shortcomings by providing a fully integrated solution where you can specify multiple user flows in a flow definition
supported by managed beans annotated with @FlowScoped and with the ability to package flows in separate
directories and JAR. Flows can also interact using inbound and outbound parameters.
@FlowScoped is a CDI scope and you must therefore enable CDI in your application by including
beans.xml in the WEB-INF/ directory or in the META-INF/ directory if the flow is packaged in Jar.
Flow definitions
You can define flows either in XML files (residing with the other flow files suffixed -flow.xml ) or in a class annotated
with @FlowDefinition . In classes annotated with @FlowDefinition you specify the flow using the FlowBuilder API,
whereas the XML file defines the flow using the XML namespace and schema.
The benefit of using the FlowBuilder is that you have full programmatic control of how the flow is defined. That is,
you can build your flows based on runtime information. The disadvantage is that it is much more difficult to quickly
get overview of the flow simply by looking at the code, unlike the XML version. Listing 5-17 shows a flow definition
expressed in XML.
Search WWH ::

Custom Search