Java Doc for AbstractFlowBuilder.java in  » Workflow-Engines » spring-webflow-1.0.4 » org » springframework » webflow » engine » builder » Java Source Code / Java DocumentationJava Source Code and Java Documentation

To give you an example of what a simple Java-based web flow builder definition might look like, the following example defines the 'dynamic' web flow roughly equivalent to the work flow statically implemented in Spring MVC's simple form controller:

 public class CustomerDetailFlowBuilder extends AbstractFlowBuilder {
 public void buildStates() {
 // get customer information
 addActionState("getDetails", action("customerAction"), transition(on(success()), to("displayDetails")));
 // view customer information               
 addViewState("displayDetails", "customerDetails", transition(on(submit()), to("bindAndValidate")));
 // bind and validate customer information updates 
 addActionState("bindAndValidate", action("customerAction"), new Transition[] {
 transition(on(error()), to("displayDetails")), transition(on(success()), to("finish")) });
 // finish
 addEndState("finish");
 }
 }
 

The first state, an action state, will be assigned the indentifier getDetails. This action state will automatically be configured with the following defaults:

1. The action instance with id customerAction. This is the Action implementation that will execute when this state is entered. In this example, that Action will go out to the DB, load the Customer, and put it in the Flow's request context.
2. A success transition to a default view state, called displayDetails. This means when the Action returns a success result event (aka outcome), the displayDetails state will be entered.
3. It will act as the start state for this flow (by default, the first state added to a flow during the build process is treated as the start state).

The second state, a view state, will be identified as displayDetails. This view state will automatically be configured with the following defaults:

1. A view name called customerDetails. This is the logical name of a view resource. This logical view name gets mapped to a physical view resource (jsp, etc.) by the calling front controller (via a Spring view resolver, or a Struts action forward, for example).
2. A submit transition to a bind and validate action state, indentified by the default id bindAndValidate. This means when a submit event is signaled by the view (for example, on a submit button click), the bindAndValidate action state will be entered and the bindAndValidate method of the customerAction Action implementation will be executed.

The third state, an action state, will be indentified as bindAndValidate. This action state will automatically be configured with the following defaults:

1. An action bean named customerAction -- this is the name of the Action implementation exported in the application context that will execute when this state is entered. In this example, the Action has a "bindAndValidate" method that will bind form input in the HTTP request to a backing Customer form object, validate it, and update the DB.
2. A success transition to a default end state, called finish. This means if the Action returns a success result, the finish end state will be transitioned to and the flow will terminate.
3. An error transition back to the form view. This means if the Action returns an error event, the displayDetails view state will be transitioned back to.

The fourth and last state, an end state, will be indentified with the default end state id finish. This end state is a marker that signals the end of the flow. When entered, the flow session terminates, and if this flow is acting as a root flow in the current flow execution, any flow-allocated resources will be cleaned up. An end state can optionally be configured with a logical view name to forward to when entered. It will also trigger a state transition in a resuming parent flow if this flow was participating as a spawned 'subflow' within a suspended parent flow.
author:
   Keith Donald
author:
   Erwin Vervaet

This criteria will only allow the Transition to complete execution if the Action completes successfully.
Parameters:
  action - the action to execute after a transition is matched butbefore it transitions to its target state the transition execution criteria

Encoded method signature format: Method without arguments:

 ${methodName}
 

 ${methodName}(${arg1}, ${arg2}, ${arg n})