[Springframework-developer] [webflow] JavaServer Faces Integration -- Proposed Requirements and Approach

[Craig M. <cra...@gm...>]

Sorry for a later initial post than I had intended -- life is never as
calm as one would hope.  I'd like to use this message to kick off
discussions around a high quality integration of Spring WebFlow with
JavaServer Faces, which I will also volunteer to help build and
maintain, and then contribute into the Spring source code base so that
everyone can benefit from it.

As background for understanding what is required to accomplish this, I
have implemented a relatively simple "dialog" mechanism (heavily
inspired by SWF) into Shale -- my next generation web application
framework that is built on top of JSF's extensible front controller
facilities (rather than treating JSF as just a view tier technology).=20
I would like to briefly explain what I've done there, and use it to
motivate further discussion about what the requirements for SWF-JSF
integration should be, and some proposed solutions based on what I've
learned so far.  However, I'm definitely going to need assistance from
Keith, Erwin, and others that are MUCH more familiar with Spring and
SWF than I am :-)


BACKGROUND - SHALE DIALOGS

Shale is a next generation web framework that I proposed to the Struts
community as "the architecture for Struts 2.x".  It did not get
accepted (by the other developers) as that, but it *did* get accepted
as a formal Struts subproject so that it can share the community
already built up around Struts, and attempt to build a community of
its own.

The starting point for information about Shale is the wiki page on it:

  http://wiki.apache.org/struts/StrutsShale

Shale is (AFAIK so far) unique among Java-based web application
frameworks in that it is designed *assuming* that JavaServer Faces
front controller facilities will be used, rather than treating JSF as
just a view tier technology (where there are integrations with many
web frameworks already, including Spring MVC and Struts 1.x).  This
assumption, as it turns out, leads to dramatically less work to do as
a framework developer -- there's a lot of beef already in existence,
plus pluggability extension points that allow a fully featured
framework to be built around the core of what JSF 1.x supplies.

In turn, that has let me focus on providing value add features on top
of the bare bones controller capabilities in JSF already.  One primary
motivation was implementing the "view helper" design pattern (also
popularized in the application model that Visual Studio supports for
ASP.NET and VB.NET applications), epitomized here in the
ViewController interface.  This particular pattern is synergistic with
the dialog support discussed below, because it tends to reduce the
number of action states required, but that's really not the focus of
ths particular discussion.

On my original set of goals for Shale was support for "dialogs" --
interactions with the user that were "longer than a request, but
shorter than a session".  I had made some initial clumsy attempts at
adding a JSF flavor around this idea.  Principally, that meant sharing
a JSF "backing bean" (the Java code where you put event handlers
associated with a page) between all the pages of a particular dialog.=20
It worked, but it was pretty clumsy.

Then, I had started hearing about SWF, and got the chance to see
Keith's presentation of it at TSSJS in Las Vegas last March.  It was
obviously a *much* better approach, so I set about learning what I
could about it.  I tend to learn by doing, so I created a fairly
simple implementation of the same concept in Shale, but kept the name
"dialog" (so that "flow" would be available when SWF was eventually
integrated :-).  The dialog support is in package
"org.apache.shale.dialog" of the core library -- and doesn't actually
have any dependencies on other parts of Shale, although applications
will benefit if they take advantage of those.  The "use cases" example
app uses this facility in the "org.apache.shale.usecases.profile"
package where two dialogs (Log On and Edit Profile) are used.  The
package Javadocs for this package include state diagrams for these two
dialogs (if you've read the SWF "Practical Guide" page, you'll know
exactly how this translates to dialog definitions ;-).

Compared to SWF, dialogs are different in the following ways:

* Action states are encapsulated as a JSF "method binding expression", whic=
h
  is an EL expression pointing at a public method of some bean (typicaly a =
JSF
  managed bean) that takes no arguments and returns a String that is interp=
reted
  as the outcome that drives the next transition.  This method signature ha=
ppens
  to match the signature used for an "action" that is invoked by a JSF comm=
and
  component (such as a submit button), and JSF already provides the express=
ion
  evaluation machinery, so it was natural to support a familiar approach.

* View states are encapsulated as the rendering of a JSF-based response,
  *plus* the processing (through the normal JSF request processing lifecycl=
e)
  of the subsequent submit.  The logical outcome string returned by the sub=
mit
  action that was ultimately invoked drives the transition from the
view state to
  the subsequent state within this dialog.

* A facility is provided such that the state information specific to a
particular
  dialog may be exposed (as a property on a session scoped bean) but
automatically
  cleaned up when the dialog completes.  This is done by calling setData(Ob=
ject)
  on the Status instance (in session scope) where the dialog facility
keeps track
  of the current state of the dialog being executed.  This "data"
object is pushed
  onto a stack when a nested dialog is entered, and popped off when the dia=
log
  is completed -- which means the application does not need to be concerned=
 with
  throwing away a session scope attribute when the outermost dialog is fini=
shed.

* As a happy consequence of the above feature, pages containing JSF compone=
nts
  can use value binding expressions to store information in this data
object, without
  any regard to which dialog is being executed (or how deeply nested
it is).  In the
  Shale sample application, the "Edit Profile" dialog has a "fullName"
field that is bound
  to a property of the local state object like this:

    <h:inputText id=3D"fullName" value=3D"#{dialog.data.fullName}"/>

  where "dialog" is the session scoped bean containing the state of the dia=
log
  computation, and "data" is the general property a dialog can use to
store state
  specific to this dialog.  The state object will be thrown away for
you when the
  dialog completes -- essentially creating a "transaction scope" even thoug=
h no
  such thing is (yet) supported by the Servlet API.

* (Recently added) it is possible to define transitions that are
global to an entire
  dialog, rather than having to explicitly define them all inside a
state definition.
  This is exactly analogous to the way that Struts allows you to define glo=
bal
  <forward> elements (for the entire application) that can get overridden o=
n a
  per-action basis by a local <forward> element.

The idea of configuring dialogs and using these facilities works out
quite well ("well, duh" says anyone already familiar with SWF :-).  It
also turned out to be incredibly simple to implement -- one of the JSF
extension points is the NavigationHandler API, which the framework
invokes after the application action returns.  It is used to drive
navigation to another page (or back to the same page, if the logical
outcome is null).  The key method signature is:

    public void handeNavigation(FacesContext context, String
fromAction, String outcome);

where "context" is an encapsulation of the state of the current
request, "fromAction" lets you distinguish between submit buttons
(that might return the same outcome) on the same form, and "outcome"
is the logical outcome that is returned by the action method.

By default, JSF supplies a mechanism that analyzes a set of navigation
rules (defined in a faces-config.xml file) to choose the next view
(typically a JSP page, but that's by no means the only option) to be
rendered.  However, this is an extension point where a framework can
provide value added facilities, or delegate to the standard machinery
if it wants to.

As currently implemented in Shale, the custom NavigationHandler
provides the following facilities:

* When no dialog is being executed, delegate to the standard
  JSF NavigationHandler implementation (so that everything the
  developer knows about JSF navigation happens as expected).

* A dialog named "xxx" is entered when an action returns a logical
  outcome of "dialog:xxx".  This approach required no change to any
  JSF (or JSF-called) APIs -- it's just a specialized interpretation of
  the logical outcome string.

* Once a dialog is entered, state transitions are managed by the custom
  NavigationHandler implementation
(org.apache.shale.dialog.faces.DialogNavigationHandler)
  in a manner very similar to what a SWF Controller does.  This includes
  the ability to nest dialogs (just like SWF can nest flows).

The end result is an environment with some very important benefits resultin=
g:

* Outside of the dialogs world, standard JSF things work in the usual way.

* Dialogs can reuse actions and view states (including those that are also
  accessed directly via standard JSF facilities), because the interpretatio=
n of
  the logical outcome is specialized per dialog.

* As with SWF, the configuration of a dialog (or a flow) is very much amena=
ble
  to tool-aided support like graphical drag-n-drop development of the
overall flow --
  as well as for more formal UML-based tool support.

* Because of the other capabilities provided by Shale, an application
will typically
  need fewer "setup" action states (because the prerender() method of a
  ViewController can take many of these responsibilities) and less work in
  what is typically a "bindAndValidate" action in Spring (because JSF has i=
ts
  own support for validation processing that preceeds such a state).  But t=
hese
  are just icing on the cake -- the key values of having managed dialogs ar=
e
  independent of Shale.


PROPOSED SWF-JSF INTEGRATION REQUIREMENTS

Given what I've learned from the above investigations, then, I'd like
to propose the following as requirements to be met by an integration
between SWF and JSF:

* When a flow is *not* being exected, all the standard JSF navigation
capabilities
  will work as expected.

* Execution of a JSF action method can cause a SWF flow to be entered, by
  returning a suitably encoded logical outcome (perhaps "flow:xxx" or
"swf:xxx" to
  invoke a flow named "xxx").  In addition, other standard approaches
to entering
  a flow will also work, of course.

* Zero or more flows may reuse the same JSF pages (and backing beans).  Thi=
s
  implies that the flow management facility will take over the
interpretation of logical
  outcomes from standard JSF action methods, which would otherwise drive th=
e
  standard navigation facilities of JSF.

* There should be a mechanism to push a local state object onto a stack, an=
d
  have it popped off on dialog completion (as Shale does) so that
applications do
  not have to worry about it.  This is not mission critical (and
indeed there might be
  facilities for this already that I haven't discovered yet :-), but
it is very important
  to usability.

* JSF applications using SWF must be able to leverage all of the sophistica=
ted
  transition management capabilities that SWF supports (as opposed to the s=
imple
  deterministic model that Shale currently provides).

* When executing a flow, a JSF view state will cause the corresponding JSF =
view
   to be rendered, *and* the flow will be suspended until the
subsequent JSF form
  submit occurs.  The logical outcome from the action method that is invoke=
d for
  the appropriate submit button will be used to drive the next transition.

    - IMPLICATION:  If JSF validation failures occur, the current page will
      be redisplayed without ever invoking the application action
method; implying
      that the current state will remain the same.  This is typically
the desired result,
      but requires no explicit transition management in a JSF-based applica=
tion.

* While executing a flow, non-JSF view states should be supported as well
  (this probably comes out of the box, but it needs to be called out).


PROPOSED IMPLEMENTATION APPROACH:

Here's where I really need some help from you guys :-).

It seems that all of the above requirements can be met, in a manner
fairly similar to what I did with Shale's dialogs, by implementing a
custom JSF NavigationHandler with the following features:

* When not currently executing a flow, standard JSF navigation is performed=
.

* When a logical outcome of the form "flow:xxx" is handed to the
handleNavigation()
   method, the flow named "xxx" is invoked at its start state.

* While a flow is invoking action and subflow states, the usual SWF process=
ing
  will occur.

* When a flow invokes a view state for a non-JSF page, the usual SWF proces=
sing
  will occur.

* When a flow invokes a view state for a JSF page, the appropriate JSF
incantations
  to create the corresponding view, and render it, will be invoked.=20
Further, the state
  of this flow will be suspended until JSF processes a subsequent form
submit, and
  invokes an application action that returns a logical outcome.  This
outcome will be
  the one used to drive a transition from the current view state to
some other state
  in the current flow (or exiting the flow, if this is also an end state).

* I don't see anything like this in the current APIs (but that doesn't
mean it doesn't
  exist :-), but it would be very useful to be able to push and pop
the current model
  data for a flow in a manner similar to what Shale does.  In
particular, this facilitates
  the use of JSF value binding expressions that have a constant
content regardless
  of nested flow execution.

* The implementation should be packaged in a JAR file that contains a
  "META-INF/faces-config.xml" resource that automatically configures
the integration
  with JSF, with no required changes to web.xml (I can help you
accomplish the same
  for the existing JSF managed bean integration as well).

Does this sound compatible with what you guys have had in mind for SWF?

Craig McClanahan