Base class for flow builders that programmatically build flows in Java configuration code.

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"),
             on(success(), to("displayDetails")));
                                                                                 
         // view customer information               
         addViewState("displayDetails", "customerDetails",
             on(submit(), to("bindAndValidate"));
                                                                             
         // bind and validate customer information updates 
         addActionState("bindAndValidate", action("customerAction"),
             new Transition[] {
                 on(error(), to("displayDetails")),
                 on(success(), to("finish"))
             });
                                                                                 
         // finish
         addEndState("finish");
     }
 }
 

What this Java-based FlowBuilder implementation does is add four states to a flow. These include a "get" ActionState (the start state), a ViewState state, a "bind and validate" ActionState, and an end marker state (EndState). 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.