Spring Web Flow, AJAX and DWR

[steveroderick]

Does anyone have an example or advice on how to access a bean in flowscope with DWR? I have seen this quote from Keith:

"Accessing flow execution state asynchronously via a JavaScript-to-Java library like DWR. In this case the flow execution key is submitted to the backend which is responsible for loading the execution from its repository to access the nessary state."

How is this done? Any pointers?

Thanks,

Steve

[klr8]

Check the following tip on how to access the flow execution from outside SWF, e.g. from your servlet/controller handling the Ajax requests:

http://www.ervacon.com/products/swf/tips/tip1.html

That combined with Keith's advice should pretty much get you started.

Erwin

[steveroderick]

Erwin,

I now have access to the bean I want within the flow execution. Is there any way to make changes to the bean? I am using DWR to add items to a collection, but no modifications to the bean are persisting across requests.

Thanks,

Steve

[Keith Donald]

Steve,

Make sure to put the flow execution back in the repository. You shouldn't need to generate a new key.

Keith

[klr8]

The system isn't really designed to allow you to update a flow execution from ouside of SWF. It's certainly possible but you'll have to do a bit of coding. Check the implementation of the FlowExecutor and the FlowExecutionRepositories for some info on how to go about updating the flow execution in the repo after modifying it.

Erwin

[Keith Donald]

I wouldn't say its not designed for it... The method you need to call is repository.putFlowExecution(key, execution). Should be that simple...
Keith

[klr8]

Well, it can be that simple if you're using the 'singlekey' repo, but when using continuations things get a bit more involved and it's not even that clear how it should be done, e.g. which continuation snapshot(s) should be updated?
That's basically what I was referring to. If you're just pulling info from the flow execution you don't have to worry about all those issues.

Erwin

[Keith Donald]

You just refer to the one with the key that was submitted. The key doesn't have to change, the user of the repository decides when if it does. So even with continuations, it seems pretty straight forward to me.

Keith

[klr8]

You just refer to the one with the key that was submitted.

That's the only option you have. But what if the user did a CTRL-N on the page you're on and then used one of the windows to modify the flow execution using AJAX. That change will also impact the other window since the flow execution keys are still the same. That's the kind of stuff I was thinking of, making it a non-trivial matter in general.

Erwin

[tort]

Many thanks to SWF team for opening new horizons in Web development. SWF shocks and makes me love it.

Consider you try to access flow execution from AJAX or launch/refresh/resume flows through SOAP handlers. In this cases user have to access flow scope when there is no flow execution on server, it is in external sorage, for example DB.

The problem is SWF has difficulties with access FlowExecution from outside flow executor:

1. We cannot get/put data like executor does, through ConversationManager. Conversation is guarenteed in memory(and visible to conversation manager) during code execution is inside launch/resume/refresh methods. Ajaxs works !between! these calls (session can expire).

2. We cannot get/put data through Repository, because, in case of continuations, it works through ConversationManager. To achieve our aims we must reproduce functions of ConversationManager in Repository. Code doubles. May be using ConversationManager inside Repository removes doubling code, but we can't because of p.1. It seems it would be better to use Repository inside ConversationManager... or create some third class, Cache, that holds functionality, shared between ConversationManager and Repository. Also Cache could act as ConversationContainer. Consider SWF works in environment that don't support sessions, for example Web Services.

Picture: ConversationManager gives access to conversation in memory, Cache acts as ConversationContainer(defines where and how to store), Repository defines when to store.

3. At any rate realization exists, but demands to rewrite both ConversationManager and Repository and surrounding classes. Reusability of existing SWF code is possible, but hard, because some classes(FlowExecutionContinuationGroup for ex.) are not public, but package-local. Strange, looking at most part of realization classes are public.

Easiest way is to make FlowExecutionContinuationGroup public and rebuild SWF. Bad way, but fast: overriding Repository and ConversationManager modules mean do 95% same as it already is in sources. Lots of work for 5% of changes. Saying shorter, inheritance blocked => use copy-paste.

Steps to access persisted FlowExecution looks like(continuations mode):
a) when put data

//get conversation key from flowExecutionKey
//get continuation key from flowExecutionKey
//extract conversation
//extract conversation group
//extract continuation
//extract flow execution
//extract active session
//extract flow scope
// populate flow scope
// serialize continuation
//persist conversation to DB

b) when get data
//get conversation key from flowExecutionKey
//get continuation key from flowExecutionKey
//extract conversation
//extract conversation group
//extract continuation
//extract flow execution
//extract active session
//extract flow scope
//extract data

Correct me please if i'm wrong.