[Springframework-developer] RE: spring webflow in progress pr3 features - seeking feedback

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

A few additional comments:

 

On #1 below we could have simple view setup action support as follows:

 

<view-state id="displaySearchCriteria" view="searchCriteria">

<action bean="phonebookActions" method="setupSearchCriteriaForm"/>

</view-state>

 

That would of course assume there was only a 'success' action result
possibility, which seems appropriate for most setup actions (e.g to populate
reference data drop downs)  If you need to handle error cases, then you'd
need to use the display-criteria elemtn with a if-false attribute.

 

One other feature I forgot to mention is the new ViewDescriptorCreator
strategy, allowing full dynamic control over the selection of a view and all
supporting model data when a view state is rendered.  This is a powerful
thing, for use like:

 

   <view-state id="myViewState" view="myStaticView"/> 
   <view-state id="myViewState"
view-creator="samples.MyCustomViewDescriptorCreator"/> 
   <view-state id="myViewState"
redirect="myRedirectView?foo=${flowScope.foo}"/>

 

The first definition uses a SimpleViewDescriptorCreator that simply selects
the same view each time.  The second definition selects a custom
ViewDescriptorCreator implementation (the most flexible).  The third
leverages a RedirectViewDescriptorCreator capable of resolving redirect
parameters from the flow request context using something like OGNL
expressions.

 

Keith

 

  _____  

From: Keith Donald [mailto:ke...@in...] 
Sent: Tuesday, May 17, 2005 9:17 PM
To: 'spr...@li...'
Subject: spring webflow in progress pr3 features - seeking feedback

 

SWF PR3 is expected to add some significant new features.  Some of these are
still in progress, but we want to get them out now for feedback. want to
make sure these are right.

 

Here they are:

 

1.	view state "display criteria" - EXPERIMENTAL

 

We are experimenting with display TransitionCriteria associatable with a
ViewState, to be tested after the state is entered but before a view
descriptor is returned for resolution and rendering.  This allows you to
execute arbitrary view pre-render logic before the view is displayed,
reducing the need for an explicit action state to execute such logic.  In
addition, if the display criteria test fails, a transition to another state
(like an error state) may be executed.

 

This is realized in its simplest form in the DTD as follows:

 

<view-state id="displaySearchCriteria" view="searchCriteria">

    <display-criteria if-false="myErrorState">

        <action bean="phonebookActions" method="setupSearchCriteriaForm"/>

          </display-criteria>

</view-state>

 

      It could get as involved as:

 

<view-state id="displaySearchCriteria" view="searchCriteria">

    <display-criteria if-false="myErrorState">

    <action-criteria true="customTrueEventId" false="customFalseEventId">

                  <action bean="phonebookActions"
method="setupSearchCriteriaForm"/>

                  <action bean="phonebookActions"
method="setupSearchCriteriaFormSecondActionMethod"/>

    </action-criteria>

          </display-criteria>

</view-state>

 

2.	annotated objects: flows, states, transitions, actions - NEARLY DONE

 

All definition objects (instances of Flow, State, Transition, Action) can
now be qualified (aka annotated) with properties - metadata.  This should
open the door for all kinds of stuff from role-based state security checks
to dynamic state decision logic based on transitional context.  We're also
adding full support for from-string property type conversion (with type
aliasing) using the new data binding infrastructure.

 

This is realized in the xml definition as follows:

 

<flow || state || action || transition>

     <property name="foo" value="12345" type="int"/>

     <property name="bar" value="some_custom_type"
type="myCustomTypeAlias"/>

     <property name="foo2" value="some_other_custom_type"
type="com.mycompany.MyFullyQualifiedType"/> 

</.>

 

This relies on a converter installed to convert from string to the target
type, with optional type aliasing to reduce typing.

 

3.	attribute mapping from xml flow definition - NEARLY DONE

 

It's now possible to specify input/output mappings for subflows directly
from within the xml definition, reducing the need to instantiate a custom
attribute mapper instance.

 

This realized in multiple ways as follows:

 

<subflow-state id="enterPassengerInformation" flow="passenger"> 

      <attribute-mapper> 

         <input name="someInputAttributeName"/>

         <input name="someOtherInputAttributeName"
as="someAdaptedInputAttributeName"/> 

         <input value="${requestScope.someAttribute}" source-type="string"
as="someAdaptedInputAttributeName" target-type="int"/> 

         <output name="someOutputAttributeName"/> 

         <output name="someOutputAttributeName"
as="someAdaptedOutputAttributeName"/>

                  .

      </attribute-mapper> 

</subflow-state>

 

 

4.	flow loaders - EXPERIMENTAL

 

There's really no benefit I see to have Flows exported in the web
application context.  A FlowAssembler could easily accept a group of flow
builder classnames and/or references to XML flow definition resources and
produce fully-configured Flow instances locatable by a FlowLocator.  This
would eliminate the need to define a FlowFactoryBean per Flow definition:
you could define all the flows of your app in a single bean definition, e.g:

 

<bean id="flowLoader"
class="org.springframework.web.flow.config.FlowLoader"/>

    <property name="locations">

        <list>

             <value>classpath:myflow.xml</value>

             <value>classpath:flows/*.xml</value>

        </list>

    <property name="classes">

        <list>

             <value>com.mycompany.MyFlowBuilder</value>

        </list>

    </property>

</bean>

 

What do you think?  Note the data binding stuff is completely independent of
webflow and really belongs as an enhancement to the core in future Spring
releases.

 

Keith