|
From: Keith D. <ke...@in...> - 2005-05-18 01:18: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.
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
|