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

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

Feedback ahead:

1. I'm not so sure about this feature. It seems kind of unelegant - =
something like your second example seems more complex than adding an =
additional action state right in front of the view state. Do you see =
many usecases for it, besides view setup logic? If that is the only real =
usecase, I guess direct support for setup logic in the view state is a =
better fit. Or maybe have like "named entry actions" to a view state, =
with normal transitions. Something like:

<view-state id=3D"displaySearchCriteria" view=3D"searchCriteria">
    <action name=3D"setup" bean=3D"phoneBookActions" =
method=3D"setupSearchCriteriaForm"/>

    <!-- action transitions -->
    <transition on=3D"setup.error" to=3D"myErrorState"/>

    <!-- view transitions -->
    <transition on=3D"submit" to=3D"doSearch"/>
</view-state>

2. I like this. How about letting the type converter be specified (it =
implies the output type so no need to specify that in that case):

<property name=3D"..." value=3D"..." =
converter=3D"com.mycompany.MyFullyQualifiedTypeConverter"/>

3. I really like this. Just one remark: why the "name" parameter? =
Wouldn't it be better to do:

<input source=3D"myValueName" target=3D"abc"/>
<input source=3D"${my.value.path}" target=3D"abc"/>

That way the source-type and target-type have a very consistent name. =
Still, this doesn't "read" as nicely as <input name=3D"a" as=3D"b"/>.

4. I like the idea as an alternative to the current FlowFactoryBean, but =
how is the FlowLocator going to get hold of the FlowLoader? Using a =
typed lookup in the context?

Erwin Vervaet
erw...@er...
  ----- Original Message -----=20
  From: Keith Donald=20
  To: spr...@li...=20
  Sent: Wednesday, May 18, 2005 3:16 AM
  Subject: [Springframework-developer] 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.

  =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