[Opensource] Is anyone actually using workflow with Controlle rForm/StateForm

[Dcomeau at xenos.com]

Thanks for the insight Aime!

I have one question though that concerns having a handle state as the first
state.  I would like to have a work flow controller, and have the first
state be a prompt state. I wasn't sure by your example...Is this type of
thing legal:

/**
 * This controller is invoked from a Transition on a Hub state.
 * <p>
 * The hub state passes a list of parameters which must be
 * verified before this controller's first prompt state is
 * shown.
 */

public class InvokedFromHubController extends Controller {

    State initialState; // which is a "handle" state
    State promptState;
    State handleState;
    State finalState;

    initialState = new VerifyDataPassedFromHub("state1", "blah");
    setInitialState(initialState);	

    promptState = new PromptMoreOptions("state2", "blah");
    handleState = new ValidateMoreOptions("state3", "blah");
    addStatePairing(promptState, handleState);

    finalState = new MyFinalState("state4-final", "blah");
    addFinalState(finalState);

}

So in the above code, the initialState does the same thing your removeDevice
state does: if it gets any errors, it returns them which should go back to
the hub state.  Can this be done?

Thanks,
Dave



--------------------------------------------
>> Dave Comeau wrote: >>
>>   - addStatePairing() still exists, but Handle states can be without
     promptStates when they are the first state in a Controller that
     is an "output path" from a hub.  
     Ex: a hub state has a prompt that lets you select a group of 
     Customers using checkboxes.  There are many branches (output paths) 
     for this hub.  Let's say one is "Email selected customers".  The first
     state in the EmailSelectedCustomersController must verify that those 
     users allow solicitation, if not the error message is displayed on the
     Hub's prompt screen. If so, the first prompt state is displayed.     


>> Aime wrote: >>

The current workflow can also handle this situation.  The sample code listed
above is an example of this.  The 'removeDevice' function transitions to a
controller/state that will not perform it's 'remove' function unless the
device meets certain criteria.  If the criteria isn't met, the hub screen is
redisplayed along with the message specified by the removeDevice state.
Here's a piece of the removeDevice state logic:

		if ( "Criteria is not met" ) {
			ErrorCollection errors = new ErrorCollection();
			errors.addError("Cannot remove device because...");
			response.saveErrors(errors);
		}	


In this situation the hub screen would be displayed along with the specified
message.
--------------------------------------------