[Springframework-developer] webflow additions

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

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

=20

=20

=20