Feedback requested: Redirect support in SWF
We have extended/refined the support for redirects in Spring Web Flow; feedback on these refinements are much appreciated.
1.0 introduced 3 redirect types: "conversation redirect", "flow redirect", and "external redirect".
A conversation redirect allows redirect to the *current* (most recent) view-state of a conversation, at a single conversation URL, while the conversation remains active.
A flow redirect requests that a entirely new execution of another flow be launched--used to support flow chaining and restart use cases.
A external redirect redirects to an arbitrary external URL, with support for sending a flow execution key through the redirect.
1.0 RC1 introduces a 4th type, called a "flow execution redirect". This supports redirecting to *any* previously traversed view-state of a flow execution at a unique "flow execution URL", to support post->redirect->get semantics with full support for back, forward, and refresh buttons while the conversation remains active.
In addition, the semantics of "conversation redirect" and "flow execution redirect" are a bit different now--previously application view selections made by view states were cached through the redirect; now they're reconstituted via a new FlowExecution "refresh" operation on each redirect request. Note this causes any data in request scope of the request preceding the redirect to be lost (while data in flow scope is preserved of course).
"itemlist" and "numberguess" samples demonstrate the "conversation redirect" (notice how back doesn't make any sense as the URL is stable throughout the flow, and it is best suited for a "SimpleFlowExecutionRepository").
"sellitem" demonstrates the "flowExecutionRedirect". Notice how the URL changes on each submit and back/forward/refresh are fully supported. Also note how this is is suited for a "ContinuationFlowExecutionRepository" and does not make sense with client-side storage.
Notice how post->redirect->get semantics can be configured globally for all flows (see FlowExecutor.redirectOnPause property) or on a per flow basis (see view-state redirect prefixes in "view" attribute DTD). Of course, redirection is optional, and samples like Phonebook don't do any redirects, relying on continuations + page caching to get stable navigation button behavior.
Thoughts? We should release 1.0 RC1 once we are confident these remaining redirect challenges are right.
Keith
Last edited by Keith Donald; Apr 29th, 2006 at 07:23 PM.
Keith Donald
Core Spring Development Team