Re: [Springframework-developer] webflow additions

[J.Enrique R. <er...@di...>]

Hi Keith, I don't know if you have started a private thread, sorry
for my answer if it is true.

We are analyzing the web-flow to extend it for Portlets
API. The work to implement web-flow support for Portlet navigation
can be big and it allways remains as a patch (wrappers, duplicate code, e=
tc)
but with this refactor it can be simpler, cleanner and consistent. You
provide an unique solution for different frameworks. We think that this
refactor is a great idea.

The Conditional transitions is a great idea too, but consider not limit
it to OGNL, for example one can choose Jakarta-JEXL, you could consider
a way to set the condition interpreter bean.

Regards.

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