RE: [Springframework-developer] webflow additions

[Keith D. <ke...@in...>]

>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.

=20

I just committed some refining for the conditional transition support.  =
The
core interface, TransitionCondition, is not tied to OGNL in any way.  =
We=92ll
most likely have an OgnlTransitionCondition for OGNL-based expressions.
Similarly, you could have Jakarta-JEXL implementation.

=20

Looking forward to hearing more about how you leveraging web-flow in a
portlet environment!

=20

Keith

=20

  _____ =20

From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
J.Enrique Ruiz
Sent: Thursday, March 17, 2005 3:14 AM
To: spr...@li...
Subject: Re: [Springframework-developer] webflow additions

=20

Hi Keith, I don't know if you have started a private thread, sorry=20
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=20
can be big and it allways remains as a patch (wrappers, duplicate code, =
etc)
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=20
a way to set the condition interpreter bean.

Regards.




Hey guys,

=20

I=92ve 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.

=20

Here=92s the scoop on new stuff:

=20

- 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=E7ade interface for managing a single executing flow =
looked
like:

=20

public interface FlowExecution {

public ModelAndView start(HttpServletRequest request, HttpServletRequest
response, Map input);         =20

public ModelAndView signalEvent(String eventId, String stateId,
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 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=92t =
seem
worth it.)

=20

- With this change, a =93FlowExecutionContext=94 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.)

=20

So for example, previously the Action interface looked like:

=20

            public interface Action {

                        public String execute(HttpServletRequest =
request,
HttpServletRequest response, MutableFlowModel model);

            }

=20

It now looks like:

=20

            public interface Action {

                        public Event execute(FlowExecutionContext =
context);

            }

=20

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 =93Event=94 object now for consistency, =
instead
of a String, to signal the result of action execution.

=20

- 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=92t 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 =93big order =
flow=94,
else continue in the regular order processing flow.

=20

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.)

=20

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 ;-)

=20

So give it a go and let me know what you think! We want a =
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...