Dear Wiki user, You have subscribed to a wiki page or wiki category on "Shale Wiki" for change notification.
The following page has been changed by CraigMcClanahan: http://wiki.apache.org/shale/DialogManagerFeature The comment on the change is: First crack at a requirements list for the dialog feature ------------------------------------------------------------------------------ = Dialog Manager Feature = + + == Introduction == The [http://shale.apache.org/features-dialog-manager.html Dialog Manager] feature of Shale shows promise in helping application developers organize large scale applications into "conversations" with the user, maintaining local state solely for the duration of that conversation (instead of letting it accumulate in session scope until the user logs off). Unfortunately, the current implementation is the subject of several outstanding bug reports: * [https://issues.apache.org/struts/browse/SHALE-10 SHALE-10] IFrame does not work properly inside Shale dialog @@ -9, +11 @@ To address these issues, it seems likely that some rearchitecture will be required. In that case, it also makes sense to go back and articulate the set of requirements that the revised functionality should support, to ensure that they all get met satisfactorily. + == Requirements == + + For an appropriate prioritization, the requirements below are separated into MANDATORY, DESIREABLE, and NICE TO HAVE buckets. Within each bucket, requirements are numbered - so any new requirements added to a bucket later should go to the end. Original requirements that we decide to remove from the list should be visually labelled in some way, to maintain the identity of the requirement numbers. + + === Mandatory Requirements === + + 1. Make implementation decisions that minimize the amount of new learning for a developer that is already familiar with JSF. + * Also, leverage existing JSF concepts such as managed beans and programmatic expression evaluation where it is useful. + 1. Support modelling of a dialog as a UML state diagram, with states embodying various kinds of processing activity and transitions between states being driven by logical outcomes from these activities. + 1. Support configuration of zero or more uniquely named dialogs within the scope of a single web application. + * An XML based configuration mechanism is required, with support for one or more configuration resources, a default resource name if none is specified, and automatic recognition of configuration resources in the META-INF section of a JAR file. + 1. Support the concept of an ''action'' state that represents a call to an arbitrary method of some arbitrary bean, which returns a logical outcome. + * Support configuration of the method to be called with a JSF method binding expression + * Logical outcome returned by this method is used to select the appropriate transition + 1. Support the concept of a ''view'' state that represents the rendering of a particular JSF view, following by a subsequent postback, up to and including Invoke Application phase. + * Logical outcome returned by the invoked action method is used to select the appropriate transition + 1. Support the concept of an ''exit'' state that causes the current dialog to be completed (throwing away any stored state information). + * Requires some mechanism for an exit state to provide a logical outcome, in order to drive transitions in a parent dialog + 1. Support the concept of a ''subdialog'' state that allows reuse of a different dialog definition as a "black box" subroutine. + * Logical outcome returned by the exit state of the invoked subdialog is used to select the appropriate transition. + 1. Context data for a currently executing dialog must be maintained while a dialog is in progress, and must be automatically thrown away when the dialog is exited. + * Must be accessible programmatically in JSF event handlers + 1. Support for multiple active dialog instances within a single page. + * Includes support for multiple instances of the same dialog name. + 1. Support for multiple active dialog instances across multiple frames or windows, including popup windows. + * Includes support for multiple instances of the same dialog name. + 1. State synchronization must deal appropriately with use of browser navigation buttons. + 1. Implementation must not modify standard JSF semantics like "return null from an action method means redisplay the current view". + 1. Must be possible to enter a dialog as a result of a JSF navigation rule. + + === Desireable Requirements === + + 1. Context information for a currently active dialog instance is accessible via a custom VariableResolver so that it can be referenced with value binding expressions. (May be difficult to disambiguate a single variable name if there are multiple active dialog instances going on.) + 1. Use of a particular JSF view in a dialog should be transparent to the page author (i.e. do not require explicit artifacts to be included in the component tree). + 1. Use of a particular JSF backing bean (such as a Shale ViewController) in a dialog should be transparent to the backing bean author, unless programmatic access to the state information for the current dialog instance is invoked. + * If EL expressions can be used to access the state, this can still be fairly transparent. + 1. Support of either a custom dialog-defined JavaBean with properties for individual state data, or a generic Map, as the holder of state data. + 1. Programmatic entry into, and exit from, a dialog instance (in addition to navigation based entry and exit state based exit). + 1. A stable public API to access the static configuration of a dialog (as opposed to the dynamic state and context of an executing dialog instance). + + === Nice To Have Requirements === + + 1. + + == Prior Art == + + Shale is certainly not the first framework to attempt an implementation of this concept (although we are trying for a distinctly "JSF feeling" implementation). + * [http://opensource.atlassian.com/confluence/spring/display/WEBFLOW/Home Spring WebFlow] + * [http://jboss.com/products/seam JBoss Seam] + * [http://jakarta.apache.org/commons/scxml Jakarta Commons SCXML] (State Chart XML) + + == Implementation Approaches == + + Add a section below for each implementation approach to be considered, including pro/con and tradeoffs in achieving the goals described above. +
