Menu
▾
▴
Re: [Springframework-developer] new feature proposal for SWF: asynchronous flows
|
From: Steven D. <ste...@in...> - 2005-09-21 13:38:31
|
Erwin,
The AJAX component I'm talking about makes a request to the SWF
controller with _flowExecutionId and _eventId parameters and replaces
the inner HTML of a div tag with the HTML returned by SWF. From the
SWF perspective not much changes.
<div id="miniWizard">
<form>
<label>Departure city</label><input type="text"
name="departure"><br>
<label>Destination city</label><input type="text"
name="destination"><br>
<input type="hidden" name="_eventId" value="myAjaxEvent">
<input type="hidden" name="_flowExecutionId" value="$
{flowExecutionId}">
<input type="button" value="Submit" id="submitButton">
<ajax:sendRequest elementId="miniWizard"
buttonId="submitButton" url="..."/>
</form>
</div>
SWF could start asynchronous flow executions from the scope of an
existing flow execution to make AJAX integration more powerful.
Steven
On 21 Sep 2005, at 14:45, Erwin Vervaet wrote:
> 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
>>
>>
>
>
>
> -------------------------------------------------------
> 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
>
>
|
