Page 2 of 3   « previous page   next page »

A FlowExecutionManager is a controller façade to the Spring Web Flow system. On receiving an event, it loads the flow defined by the '_flowId' parameter using Spring's bean factory (using XMLFlowFactoryBean). Then, it looks for an event parameter '_flowExecutionId' and if it isn't present, it will create a new FlowExecution instance and uses it to start this new flow. A FlowExecution encapsulates the execution state of a flow. Otherwise, the flow execution manager loads the existing flow execution instance from its storage (in our case this is HTTP Session-based storage) and uses it to continue execution. Figure 4 depicts this as a UML sequence diagram.

[Spring provides standard controllers to integrate with Spring MVC and struts framework. The controller servlet shown in Figure 4 and Figure 5 shows the logic that goes into these controllers.]

Let's look at each state in our sample checkout flow.

The 'viewShoppingCart' is a view state (it's also the start state). When the flow enters a view state, it triggers the rendering of a view. The view name defined by the 'view' attribute of any view state is a logical name that needs to be mapped to a physical view. In Spring MVC a ViewResolver and in struts an ActionForward can do this mapping. When the flow execution enters the 'viewShoppingCart' state, the flow execution suspends the active flow and returns a ViewDescriptor that represents a logical view 'sc.view.' A controller servlet can now map this logical view to a JSP (or any other view type) and forward the request to that JSP to render the view.

Once the user selects 'next' on the view shopping cart page, the controller servlet uses the flow execution manager to resume the flow execution. The flow execution manager requires the following parameters to continue flow execution:

• flowExecutionId - denotes the current flow execution state. [Required]
• currentStateId - denotes the current state. [Optional - required only to support browser back button usage]
• eventId - denotes the generated event. [Required]

//Lookup flow execution manager from spring's context
FlowExecutionManager mgr = ...
Map params = new HashMap();
// copy all request parameters to params HashMap
Event event= new Event(source, eventId, params);
ViewDescriptor vd = mgr.onEvent(event);
...

Figure 5 depicts this as a sequence diagram.

The flow execution manager loads the flow execution from the storage and uses it to process the event. The flow execution instance will apply the event on the known current state (the supplied current state will override this), which will result in a transition to a new state.

In our case, the current state is 'viewShoppingCart' and the '_eventId' value is 'next.' Since there's a transition defined for this criterion, it's executed and the flow execution enters the target state 'viewShippingAddress.' This will display the shipping address page to the user. Had the '_eventId' value been 'cancel' it would have resulted in entering the 'cancelFlow' state.

If the user now inputs the shipping details and selects 'next,' it should take the flow to the 'bindAndValidateSA' state, which is an action state. An action state executes one or more implementations of the 'Action' interface when entered. A typical action can act as a bridge between the presentation tier and the business tier or even execute the business logic directly (not a good practice).

The SWF supplies a ready-made 'action' implementation 'FormAction' for binding form parameters to a POJO bean. The 'FormAction' class extends from 'MultiAction,' which gives it the ability to dispatch a given method at runtime. The method to be executed can be specified using a 'method' attribute to an 'action' in the Web flow configuration.

In our example, we haven't specified a 'method' attribute and hence the default behavior is to execute a method with the same name as the state id, which is 'bindAndValidate.' The default implementation of the method 'bindAndValidate' in 'FormAction' dynamically binds the event parameter values to a POJO form bean, validates the bean if a 'validator' is specified, and finally places the form bean in the specified scope (flow scope or request scope).

In the checkout flow definition, the 'bindAndValidateSA' state has an action configured with a bean property of 'checkout.shippingAddress.' This is resolved using Spring's context XML.

<bean id="checkout.shippingAddress"
class="org.springframework.web.flow.action.FormAction">
   <property name="formObjectName" value="shippingAddress"/>
   <property name="formObjectClass" value="checkout.beans.ShippingAddress" />
   < property name="formObjectScopeAsString" value="flow" />
</bean>

This form action uses the POJO 'checkout.beans.shippingAddress' and puts it in flow scope after binding the event parameter values. When this action completes execution, it signals a 'success' event. This 'success' event selects the transition that takes the flow to the 'viewBillingAddress' state. The flow then continues to execute this new state and so on.

When the flow enters an end state, it terminates the flow and displays the configured view.

<end-state id="finishCheckout" view="homePage" />

Sub Flows
Spring Web Flow also supports sub-flows. A sub-flow is a logically separate but complete flow in itself. It's similar to a subroutine in a procedural language. SWF has a separate state to denote a sub-flow. A sub-flow state can also refer to a flow defined in another flow definition file.

<subflow-state id="lookupPreviousShippingDetails" flow="shippingDetailsLookupFlow">
   <attribute-mapper >
    <input name="customerId"/>
    <output name="shippingAddress">
   </attribute-mapper>
   <transition on = "success" to = "viewShippingAddress">
</subflow-state>

Page 2 of 3   « previous page   next page »