Re: [Springframework-developer] new feature proposal for SWF: asynchronous flows

[Erwin V. <erw...@er...>]

We already have asynchronous flows: you can start any number of top-level 
flow executions concurrently.

So what exactly is the benefit of the additional support you describe? Why 
can't you just use a subflow or a second independent top-level flow for 
those 'mini wizards' you describe? I'm not sure all the added complexity 
really pays off...

Stuff like "When the view state of the parent transitions the flow 
executions of the asynchronous flows are terminated. The FlowAttributeMapper 
can be used in the same way as with sub states to  map scope attributes 
between a parent flow and asynchronous flows." and "In this scenario it may 
be desirable to allow an end state of an  asynchronous flow to trigger the 
transition of the view state of the parent" is a bit strange IMHO: if you 
want that kind of stuff, just use subflows and a flow execution listener.

Also, it seems that terminating all started asynchronous flows when the 
'parent' transitions could lead to a number of issues. What if a client 
spawned multiple ansynchronous flows and one triggers a transition in the 
parent. As a result all those 'mini wizards' would become unusable...

Erwin

> I've skyped with Keith today about a new feature I would like to see 
> added to SWF: asynchronous flows (useful with AJAX technology).
>
> Asynchronous flows are normal SWF flows that are launched  asynchronously 
> from a view state, typically thru AJAX calls, separate  browser windows or 
> frames.
>
> An asynchronous flow is thus a flow definition that is started  through an 
> event id that's defined in a view state:
>
> <view-state id="myViewState" view="myView">
>     <transition on="submit" to="myActionState"/>
>     <async-flow on="myAsyncEvent" flow="myAsyncFlow"/>
> </view-state>
>
> When an asynchronous flow is launched the parent flow execution is  not 
> transitioned. Asynchronous events are accessible through the flow 
> execution id of the parent. When an asynchronous flow has been  started a 
> new flow execution is created and that flow execution is  referenced to by 
> a new flow execution id. This allows for multiple  invocations of the same 
> asynchronous flow by the same client. When an  asynchronous flow execution 
> ends it can trigger the transition of the  parent view state (more on that 
> later).
>
> Otherwise asynchronous flows have the exact same behavior of normal  SWF 
> flows. They can have action states, view states, subflow states  and 
> decision states. When the view state of the parent transitions  the flow 
> executions of the asynchronous flows are terminated. The 
> FlowAttributeMapper can be used in the same way as with sub states to  map 
> scope attributes between a parent flow and asynchronous flows.
>
> A typical use case for an asynchronous flow is a mini-wizard  contained as 
> a widget in a view. The asynchronous flow is launched by  an AJAX 
> client-side HTTP component that replaces the inner html of a  div tag with 
> the html send back by the view states of the  asynchronous flow (a normal 
> JSP views for example). We probably need  a JSP tag that renders the 
> client-side JavaScript:
>
> <ajax:sendRequest eventId="myMiniEvent" flowExecutionId="$ 
> {flowExecutionId}"/>
>
> This JSP tag can than be used in the views of asynchronous flows to  mimic 
> browser behaviour. This feature could make creating mini- wizards child's 
> play. It should be noted that when the view is shown  by the browser and 
> the JavaScript code of the JSP tag kicks it will  immediately launch a 
> call to the asynchronous event. A optimization  could be to let this JSP 
> tag execute the call to asynchronous flow on  the server if that's 
> feasible.
>
> An example of a AJAX mini-wizard is a section on the site of a travel 
> booking agent where:
>
>  - your can enter a departure and destination city on the first page
>  - next a page to confirm the names of the cities
>  - then a page to select the dates of departure and return and
>  - then a page with a list of available flights
>
> In this scenario it may be desirable to allow an end state of an 
> asynchronous flow to trigger the transition of the view state of the 
> parent, for example when a flight in the mini-wizard is clicked on.  Since 
> the flow execution of the mini-flow only knows its own flow  execution id 
> the id of the parent cannot be used. For this scenario  we could use the 
> name of the asynchronous flow + the name of the end  state as the event 
> name of a transition on the parent view state:
>
> <view state ...>
>    <async-flow on="myAsyncEvent" flow="myAsyncFlow"/>
>    <transition on="myAsyncFlow.myEndState" to="myNextState"/>
> </view-state>
>
> Mini-wizards can also be displayed in a pop up browser window when 
> selecting items to complete a form, for example to select products in  an 
> order form. These mini-wizards obviously also can be implemented  as AJAX 
> mini-wizards.
>
> Any thoughts?