Re: [Springframework-developer] webflow additions

[Rob H. <ro...@ca...>]

Looking good Keith - these improvements should really consolidate the 
web flow framework. When I get back home, I'll spend some time looking 
at the OGNL integration if you haven't already done it by then.

Rob

Keith Donald wrote:

> Hey guys,
>
> I’ve been working on adding a good deal of new stuff to web flow as a 
> result of good feedback from TSSJS. Happy to say it is now at a state 
> ready for you guys to review again. I just got the Phonebook sample 
> app in samples/webflow/phonebook back working this evening.
>
> Here’s the scoop on new stuff:
>
> - Flow execution event processing is now fully decoupled from the HTTP 
> servlet request and response objects. This makes it possible for 
> clients in different environments to start new flow executions, and 
> signal events in ongoing flow executions. I would now expect 
> integration with other frameworks/technologies like Tapestry, JSF, 
> Beehive, Porlets, etc. to be straightforward. To get you an idea of 
> the differences, previously the central client façade interface for 
> managing a single executing flow looked like:
>
> public interface FlowExecution {
>
> public ModelAndView start(HttpServletRequest request, 
> HttpServletRequest response, Map input);
>
> public ModelAndView signalEvent(String eventId, String stateId, 
> HttpServletRequest request, HttpServletRequest response);
>
> }
>
> Now it looks like:
>
> public interface FlowExecution {
>
> public ViewDescriptor start(Event startingEvent);
>
> public ViewDescriptor signalEvent(event);
>
> }
>
> I think this is a good deal better. To define a different source of an 
> event (e.g HttpServletRequestEvent, FacesEvent, etc.), create a custom 
> event subclass. Note: ModelAndView was changed to ViewDescriptor to 
> remove the dependency on spring mvc (as that was the ONLY dependency, 
> and didn’t seem worth it.)
>
> - With this change, a “FlowExecutionContext” object has been 
> introduced. It is now the central object passed to most 
> user-implemented constructs in the system, for accessing contextual 
> information about the ongoing flow execution. Constructs effected 
> include things like flow Actions (to bridge between the web tier and 
> the middle tier) and conditional transitions (to effect the path 
> through a flow dynamically based on context.)
>
> So for example, previously the Action interface looked like:
>
> public interface Action {
>
> public String execute(HttpServletRequest request, HttpServletRequest 
> response, MutableFlowModel model);
>
> }
>
> It now looks like:
>
> public interface Action {
>
> public Event execute(FlowExecutionContext context);
>
> }
>
> The new sig is good deal cleaner. The context object provides access 
> to a requestScope() and a flowScope(), for storing and reasoning on 
> arbitrary model data in different scopes. You can now access a good 
> deal more contextual information about the lifecycle of the flow 
> execution with this object. Note: Action returns an “Event” object now 
> for consistency, instead of a String, to signal the result of action 
> execution.
>
> - Conditional transitions are another new feature that we expect to 
> further enhance upon before the preview release. Previously, you could 
> define a custom condition to determine, given the occurrence of an 
> event in a state of the flow, what state to go to next. But you 
> couldn’t really take into account additional contextual information 
> (like arbitrary event parameters, or data in request or flow scope, 
> for example.) Now transitional expressions have full-access to the 
> FlowExecutionContext, which gives them a lot more to reason on to make 
> dynamic state transition decisions. For example, something like: if 
> ${order.price} > 5K} spawn the “big order flow”, else continue in the 
> regular order processing flow.
>
> Now we want to expand on the above, to include declarative transition 
> expressions in the flow definition DTD using something like OGNL. 
> Currently you can only define rich expressions programmatically (which 
> is fine, but OGNL support would be sweet.)
>
> Those are the central new features (in addition to the instantiation & 
> autowiring capability I noted yesterday for Actions). The http request 
> decoupling was the biggie. I just finished getting javadocs back up to 
> date, and tests are finally also back in line. Next up is wiki docs ;-)
>
> So give it a go and let me know what you think! We want a 
> stable-as-possible preview release real soon!
>
> Keith
>