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

[Erwin V. <erw...@er...>]

Regarding the view state: with named entry actions we could have =
everything without even doing stuff like the "display-criteria" with =
"if-false" and stuff like that. See my earlier mail.

Erwin Vervaet
erw...@er...
  ----- Original Message -----=20
  From: Keith Donald=20
  To: spr...@li...=20
  Sent: Wednesday, May 18, 2005 5:02 AM
  Subject: [Springframework-developer] RE: spring webflow in progress =
pr3 features - seeking feedback


  A few additional comments:

  =20

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

  =20

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

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

  </view-state>

  =20

  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.

  =20

  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:

  =20

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

  =20

  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.

  =20

  Keith

  =20


-------------------------------------------------------------------------=
-----

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

  =20

  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.

  =20

  Here they are:

  =20

    1.. view state "display criteria" - EXPERIMENTAL=20
  =20

  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.

  =20

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

  =20

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

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

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

            </display-criteria>

  </view-state>

  =20

        It could get as involved as:

  =20

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

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

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

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

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

      </action-criteria>

            </display-criteria>

  </view-state>

  =20

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

  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.

  =20

  This is realized in the xml definition as follows:

  =20

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

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

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

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

  </.>

  =20

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

  =20

    3.. attribute mapping from xml flow definition - NEARLY DONE=20
  =20

  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.

  =20

  This realized in multiple ways as follows:

  =20

  <subflow-state id=3D"enterPassengerInformation" flow=3D"passenger">=20

        <attribute-mapper>=20

           <input name=3D"someInputAttributeName"/>

           <input name=3D"someOtherInputAttributeName" =
as=3D"someAdaptedInputAttributeName"/>=20

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

           <output name=3D"someOutputAttributeName"/>=20

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

                    .

        </attribute-mapper>=20

  </subflow-state>

  =20

  =20

    4.. flow loaders - EXPERIMENTAL=20
  =20

  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:

  =20

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

      <property name=3D"locations">

          <list>

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

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

          </list>

      <property name=3D"classes">

          <list>

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

          </list>

      </property>

  </bean>

  =20

  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.

  =20

  Keith=20