!!!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.