One of the frustrating aspects of organizing the flow of control in a web based application is that fact that it is composed of completely disconnected interactions with the client (via the HTTP protocol). The popularity of application frameworks based on model-view-controller (MVC) principles, and particularly the emergence of the front controller design pattern, have become the de facto standard architectural approach.
Like other frameworks, JavaServer Faces supports a mechanism
to define navigation rules for transitions between views. The
actual processing is performed by an implementation of
standard implementation provided by the framework (which can be
customized via a pluggable API) performs transitions from one view
to another based on three inputs:
Action.execute()methods that return a logical
ActionForwarddescribing the outcome of performing the action.
However, it is still difficult to reuse individual views in more than one "conversation" or "dialog" with the user, nor to treat one dialog as a "black box" subroutine that can be called by more than one calling dialog. To address these needs, Shale offers Dialog Manager support.
The functionality of this feature was heavily inspired by the implementation of Spring Webflow (Preview 2), whose home page is:
Conceptually, a dialog can be thought of as a set of labelled states, connected by labelled transitions between those states. Indeed, a UML State Diagram is a popular way to represent the architecture of such a dialog. Each dialog has a specified starting state (with an automatic transition to this state when the dialog is first started), and one or more ending states.
Shale supports four state types, with specific implementations realized as described below.
ViewControllerbean that you've associated with the current page) is used to drive the transition to the next state, as described below.
It is not required that all JavaServer Faces
interactions be organized into dialogs -- you can have a mix of
dialog and standard navigation processing. Indeed, to enter a
dialog in the first place, simply have one of your standard action
methods return a logical outcome of dialog:xxxxx,
which will cause the dialog named
xxxxx to be entered
at its starting state. Once that dialog completes, standard
JavaServer Faces navigation will resume.
The configuration of a Dialog is represented as a tree of
JavaBeans defined in the
package, rooted at an instance
Dialog. The set of
Dialog instances is stored in a
keyed by dialog identifier, which is stored in an application scope
attribute named by symbolic constant
Dialog instances may be configured by any desired
mechanism; however, the most commonly used will likely be an XML
document that conforms to a DTD provided by Shale.
To use the Dialog Manager facilities in Shale, take the following steps:
ViewControllerbeans) that comprise your dialog, using standard JavaServer Faces and (optional) Shale
/WEB-INF/dialog-config.xml, that conforms to the required DTD, which defines all the state transitions:
<!DOCTYPE dialogs PUBLIC "-//Apache Software Foundation//DTD Shale Dialog Configuration 1.0//EN" "http://struts.apache.org/dtds/shale-dialog-config_1_0.dtd"> <dialogs> <dialog name="First Dialog Name" start="Start State Id"> ... <action/>, <view/>, <subdialog/>, and <exit/> elements for states ... </dialog> <dialog name="Second Dialog Name" start="Start State Id"> ... <action/>, <view/>, <subdialog/>, and <exit/> elements for states ... </dialog> ... </dialogs>
<context-param> <param-name>org.apache.shale.dialog.CONFIGURATION</param-name> <param-value>/WEB-INF/foo.xml,/WEB-INF/bar.xml</param-value> </context-param>
/WEB-INF/dialog-config.xmlwill be automatically processed, if it exists.