On this page we will discuss the latest integration issues for Spring Web Flow (SWF) in RSF in the context of the SWF "Hotel Booking sample" sample. This page is meant for those who are familiar with SWF and RSF. if you are new to either one you should start on the RSF-SpringWebFlow page.

Markup issues

The original sample was written using Facelets, a technology for JSF which allows a form of XHTML templating. This was further enhanced by the addition of tags from Spring Faces, the JSF integration for Spring Web Flow which is new for SWF 2.0. A sample of the Facelets markup is shown here:

Whilst this is much improved over the JSP equivalent, in that it is a reasonably valid XHTML document, this markup is still unfriendly to designers, and also will give no useful behaviour when previewed in a browser. The tags in namespaces <f: and <h: will generally either not render at all, or else be skipped until valid XHTML tags are found within their body.

Not only does this use only recognised XHTML tags <label, <select, <option, which leads to this entire page previewing in the filesystem (check out the project in SVN, and browse to src/main/webapp/content/templates/bookingForm.html), there are also fewer tags. In a Facelets/JSF application, designer control generally ceases at the point where a component tag (e.g. <h:selectOneMenu appears - the markup at this point is replaced by that chosen by the component designer, written into the taglib. In RSF, the tags written in the templates are precisely the ones rendered, down to the last tag and attribute. Therefore there is no need for the extra layer of <div containment which is necessary to apply the CSS style target id input to the control - we can simply write this directly onto the <select tag itself. Similarly for the remainder of the document.

Outer templates

Like the Facelets composition system, RSF allows markup templates to be drawn up that can be "included" from anywhere else in the application, using its Outer Page Templates scheme. Unlike Facelets compositions, this again occurs without the need for custom tags, and without compromising previeawability.

Application transparency

RSF is a "model free" framework. This does not mean it has no model layer, rather that it has no model definitions within the framework that require wrapping of client model definitions. Unlike JSF's Table, List and Tree model classes, RSF view trees are generated programmatically using normal Java code constructs such as for loops. The original sample contains a utility class SerializableListDataModel which is required to adapt the Booking and Hotel Lists used in the application to JSF's requirements. In RSF, we perform such iteration directly in code:

Validation

The current validation code in the Spring Faces sample is labelled as provisional and will be replaced by a more scripted style in future versions of Spring Web Flow. As it stands it has dependencies on both JSF and on SWF and requires to be recast. In the RSF version of this app we fall back to a pure Spring Binding approach, using the standard Spring framework FormAction action handler and Spring Validators. Some (non-RSF-dependent) extensions are provided for this model, making it highly convenient and compact to specify validation rules in a technology-neutral fashion. ultimately paving the way for client-side validation. Here is the definition for the "Booking action" bean, replacing the custom BookingActions held in the original application:

and then the remainder of the booking flow setup code, responsible for constructing the initial booking record, packaged as the createFormObject method of the FormAction (now extending the intermediate helper class ValidatorFormAction:

Spring Web Flow 2.0 final is expected to have facilities to avoid this lookup code. RSF version 0.8 will independently feature lookup-free handling of all kinds of "intermediate" scopes, such as flow, session and conversation. We have at least so far managed to remove all non-SWF dependencies from this application beyond the rendering layer.

Automatic AJAX transparency

Keeping track of flow keys and URL state can be a hazard when trying to conduct AJAX development together with SWF. RSF's ViewParameters scheme allows us to abstract all these details away - the framework automatically applies a flow-state-specific "fixup" to any URLs issued to clients to ensure they are properly nested within any current flow state. This enables the full set of RSF AJAX-enabled components, such as the internationalised date widget, to be used transparently within an SWF application with no modification. The AJAX round-trips performed by the widget are automatically "fixed up" to access the current flow state. As more components are developed as part of the Fluid UI Project this will fruitfully feed forwards into a stream of fully accessible, flexible and generic which are usable both within SWF and without.