The easiest and most natural way to declare and manage the model is through the use of flow variables. You can declare these variables at the beginning of the flow, as follows:spring-doc.cadn.net.cn

You can then reference this variable in one of the flow’s JSF view templates through EL, as follows:spring-doc.cadn.net.cn

Note that you do not need to prefix the variable with its scope when referencing it from the template (though you can do so if you need to be more specific). As with standard JSF beans, all available scopes are searched for a matching variable, so you could change the scope of the variable in your flow definition without having to modify the EL expressions that reference it.spring-doc.cadn.net.cn

You can also define view instance variables that are scoped to the current view and that automatically get cleaned up upon transitioning to another view. This is quite useful with JSF, as views are often constructed to handle multiple in-page events across many requests before transitioning to another view.spring-doc.cadn.net.cn

To define a view instance variable, you can use the var element inside a view-state definition, as follows:spring-doc.cadn.net.cn

Though defining autowired flow instance variables provides nice modularization and readability, occasions may arise where you want to use the other capabilities of the Spring container, such as Aspect-oriented Programming (AOP). In these cases, you can define a bean in your Spring ApplicationContext and give it a specific web flow scope, as follows:spring-doc.cadn.net.cn

The major difference with this approach is that the bean is not fully initialized until it is first accessed through an EL expression. This sort of lazy instantiation through EL is quite similar to how JSF-managed beans are typically allocated.spring-doc.cadn.net.cn

The need to initialize the model before view rendering (such as by loading persistent entities from a database) is quite common, but JSF itself does not provide any convenient hooks for such initialization. The flow definition language provides a natural facility for this through its actions . Spring Web Flow provides some extra conveniences for converting the outcome of an action into a JSF-specific data structure. The following example shows how to do so:spring-doc.cadn.net.cn

The preceding example takes the result of the bookingService.findBookings method and wraps it in a custom JSF DataModel so that the list can be used in a standard JSF DataTable component, as follows:spring-doc.cadn.net.cn

In the example shown in the preceding section, result-type="dataModel" results in the wrapping of List<Booking> with a custom DataModel type. The custom DataModel provides extra conveniences, such as being serializable for storage beyond request scope as well as access to the currently selected row in EL expressions. For example, on postback from a view where the action event was fired by a component within a DataTable, you can take action on the selected row’s model instance, as follows:spring-doc.cadn.net.cn

Spring Web Flow provides two custom DataModel types: OneSelectionTrackingListDataModel and ManySelectionTrackingListDataModel. As the names indicate, they keep track of one or multiple selected rows. This is done with the help of a SelectionTrackingActionListener listener, which responds to JSF action events and invokes the appropriate methods on the SelectionAware data models to record the currently clicked row.spring-doc.cadn.net.cn

To understand how this is configured, keep in mind that the FacesConversionService registers a DataModelConverter against the alias dataModel on startup. When result-type="dataModel" is used in a flow definition, it causes the DataModelConverter to be used. The converter then wraps the given List with an instance of OneSelectionTrackingListDataModel. To use the ManySelectionTrackingListDataModel, you need to register your own custom converter.spring-doc.cadn.net.cn

A simple but common case in JSF is the need to signal an event that causes manipulation of the model in some way and then redisplays the same view to reflect the changed state of the model. The flow definition language has special support for this in the transition element.spring-doc.cadn.net.cn

A good example of this is a table of paged list results. Suppose you want to be able to load and display only a portion of a large result list and let the user page through the results. The initial view-state definition to load and display the list would be as follows:spring-doc.cadn.net.cn

You can construct a JSF DataTable that displays the current hotels list and then place a More Results link below the table, as follows:spring-doc.cadn.net.cn

This commandLink signals a next event from its action attribute. You can then handle the event by adding to the view-state definition, as follows:spring-doc.cadn.net.cn

Here, you handle the next event by incrementing the page count on the searchCriteria instance. The on-render action is then called again with the updated criteria, which causes the next page of results to be loaded into the DataModel. The same view is re-rendered, since there was no to attribute on the transition element, and the changes in the model are reflected in the view.spring-doc.cadn.net.cn

The next logical level beyond in-page events are events that require navigation to another view, with some manipulation of the model along the way. Achieving this with pure JSF would require adding a navigation rule to faces-config.xml and likely some intermediary Java code in a JSF managed bean (both tasks requiring a re-deploy). With the flow definition language, you can handle such a case concisely in one place in a way similar to how in-page events are handled.spring-doc.cadn.net.cn

Continuing with our use case of manipulating a paged list of results, suppose we want each row in the displayed DataTable to contain a link to a detail page for that row instance. You can add a column to the table containing the following commandLink component, as follows:spring-doc.cadn.net.cn

This raises the select event, which you can then handle by adding another transition element to the existing view-state, as follows:spring-doc.cadn.net.cn

Here, the select event is handled by pushing the currently selected hotel instance from the DataTable into flow scope so that it may be referenced by the reviewHotel view-state .spring-doc.cadn.net.cn

JSF provides useful facilities for validating input at field-level before changes are applied to the model. However, when you need to then perform more complex validation at the model-level after the updates have been applied, you are generally left with having to add more custom code to your JSF action methods in the managed bean. Validation of this sort is something that is generally a responsibility of the domain model itself, but it is difficult to get any error messages propagated back to the view without introducing an undesirable dependency on the JSF API in your domain layer.spring-doc.cadn.net.cn

With Web Flow, you can use the generic and low-level MessageContext in your business code, and any messages added there are then available to the FacesContext at render time.spring-doc.cadn.net.cn

For example, suppose you have a view where the user enters the necessary details to complete a hotel booking, and you need to ensure the Check In and Check Out dates adhere to a given set of business rules. You can invoke such model-level validation from a transition element, as follows:spring-doc.cadn.net.cn

Here, the proceed event is handled by invoking a model-level validation method on the booking instance, passing the generic MessageContext instance so that messages may be recorded. The messages can then be displayed along with any other JSF messages in the h:messages component.spring-doc.cadn.net.cn

JSF provides built-in support for sending Ajax requests and performing partial processing and rendering on the server-side. You can specify a list of IDs for partial rendering through the <f:ajax> facelets tag.spring-doc.cadn.net.cn

In Spring Web Flow, you also have the option to specify the IDs to use for partial rendering on the server side with the render action, as follows:spring-doc.cadn.net.cn