SWFViewParams - RSF and SWF navigation schemes#

The RSF and SWF 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 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 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.