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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Steven,

I must admit I've never used AJAX stuff in the real world, so I might just 
be missing something, but could you try to explain why SWF is so usefull for 
AJAX based 'mini wizards'?

Naively I would say that SWF and AJAX are pretty orthogonal: SWF managing 
the high-level flow of a wizard for instance, AJAX being used to pull in 
dynamic data at particular pages in the wizard. So it seems that at the 
server side, the flow and the AJAX controllers are pretty much independent. 
I can imagine some AJAX controller pulling dynamic data from some data 
source and returning it as XML is used both in a SWF managed wizard and from 
another stand-alone page, possibly a simple HTML page.

Erwin Vervaet
erw...@er...
----- Original Message ----- 
From: "Steven Devijver" <ste...@in...>
To: <spr...@li...>
Sent: Wednesday, September 21, 2005 12:16 PM
Subject: Re: [Springframework-developer] new feature proposal for SWF: 
asynchronous flows

> Erwin,
>
> On 21 Sep 2005, at 10:58, Erwin Vervaet wrote:
>
>> 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...
>>
> Subflows are not the same thing since they require a transition of  the 
> parent flow execution. Either each step in a mini-wizard would  then 
> require a separate view template for the entire page, not just  the 
> section. Or javascript code makes the call and triggers the  transition of 
> the parent flow execution. This would mean all other  possible transitions 
> in other sections of the page become unavailable.
>
> Top-level flows that are executed via javascript solve this problem  since 
> the parent or original flow execution is not transitioned.  However, no 
> scope data can be copied between the original flow and  request scope and 
> the new flow scope. Making the transition on the  parent could be achieved 
> through javascript but that's leaves the  developer with boilerplate 
> javascript code.
>
>> 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.
>>
> Again, I don't agree. To me these semantics make sense from an AJAX 
> perspective. Subflows are great to synchronously execute page flows.  AJAX 
> however is about asynchronous execution.
>
>> 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...
>
> On the other hand, if you call top-level flows asynchronously thru  AJAX 
> they become stale once the original flow execution transitions.  About the 
> issues that could arise by terminating asynchronous flows:  they are real 
> and in my opinion unavoidable but should be dealt with  by the developer. 
> Once you start using AJAX on your website thru the  functionality I 
> propose you may want to use it in multiple levels  meaning other 
> asynchronous flow executions will not be terminated  just like that. It's 
> a design choice and AJAX is a very popular one.  I think it's up to the 
> developers to decide how they want to use SWF.
>
>>
>> Erwin
>
> Steven
>
>>
>>
>>> 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?
>>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by:
>> Tame your development challenges with Apache's Geronimo App Server. 
>> Download
>> it for free - -and be entered to win a 42" plasma tv or your very own
>> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. 
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
> 