| At line 1 added 41 lines |
| !!!SWFViewParams - RSF and SWF navigation schemes |
|
| The RSF and [SWF|SpringWebFlow] approaches to navigation are quite different. In RSF, a particular [ViewParameters] object represents a definite resource, or view. In SWF on the other hand, the URL attached to navigation link or control does not designate an actual resource but a ''rule by which a resource may be looked up''. In particular each SWF URL which will cause navigation within a live flow contains a ''flow execution key'' as well as an ''event id'', signalling the label of the event the user wishes to produce. The key and the event together are looked up to a transition in the current flow, which is then executed until the flow once more arrives at a "view state" which can be rendered to the user. |
|
| The [integration|RSFSpringWebFlow] has been keen to preserve the core value points of both RSF and SWF, and so view location in an RSF-SWF application is done by a "hybrid scheme", which preserves the type-safety and transparency of RSF ViewParameters in the RSF world, whilst allowing the raw request parameters state to be addressed in the SWF world. A link to an RSF-SWF flow launch or transition is done using one of the special ViewParameters types supplied with the integration, being {{SWFLaunchViewParams}} and {{SWFEventViewParams}}. |
|
| !!Firing a flow event |
|
| For example, to create a link which uses (in HTTP) a GET request to fire an event {{select}} within the current flow, we could use: |
|
| {{{ |
| UIInternalLink.make(row, "details-view", person.getUserId(), |
| new SWFEventViewParams("select", new PersonViewParams(person.getId()) |
| )); |
| }}} |
|
| Note that all {{SWFViewParams}} can accept a standard RSF ViewParameters as a further optional argument. This URL information will be "tunnelled" through the flow lookup, and can be retrieved in the final concrete view by means of the standard RSF [ViewParamsReporter|ViewParameters] scheme. |
|
| !!Launching a new flow |
|
| A new flow, with flow ID {{search-flow}} can be launched with a definition like this: |
|
| {{{ |
| UIInternalLink.make(tofill, "search-criteria", new SWFLaunchViewParams("search-flow")); |
| }}} |
|
| !!Defining your own SWFViewParams |
| The standard SWFViewParams class out of the box routes the outer navigation information through a "fictitious" view named {{_webflow}}. Much like in SWF+SpringMVC, you can allocate different flows to different "apparent views" by either deriving your own subclasses from SWFViewParams with different defaults/constructors, or setting the [viewID] field in the outer SWFViewParams by hand. |
|
| In this case you will need to register with RSF that your new "views" are handled by the SWFViewParams system by means of a {{viewParamsRegistrarParent}} definition, at application scope, like the following: |
|
| {{{ |
| <bean id="default-RSFSWF-view" parent="viewParamsRegistrarParent"> |
| <property name="viewID"> |
| <util:constant |
| static-field="uk.org.ponder.rsf.swf.viewparams.SWFViewParams.SWF_VIEW" /> |
| </property> |
| <property name="viewParamsClass" value="uk.org.ponder.rsf.swf.viewparams.SWFViewParams"/> |
| </bean> |
| }}} |
| This is actually the standard RSF-SWF framework definition that registers the {{_webflow}} "view" as requiring the SWFViewParams ViewParameters type, and hence, participating in the SWF system. |
