struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@gmail.com>
Subject Re: [Struts Wiki] Update of "StrutsShale" by CraigMcClanahan
Date Mon, 02 May 2005 18:26:16 GMT
On 5/2/05, gvanmatre@comcast.net <gvanmatre@comcast.net> wrote:
> Criag,
> 
> > If you'd like to see what an application user has to do to leverage
> > the "dialog" facility of Shale (similar in spirit to Spring WebFlow,
> > but customized for tight integration with JSF), see the package
> > documentation for the "org.apache.shale.usecases.profile" package in
> > the Shale Use Cases example app.
> >
> 
> I was looking at the new logon usecase that uses the new Dialog facility.  It looks very
interesting.

I sure think so :-).

> 
> It appears that all of navigation rules are handled by the dialog controller so that
you define them once in the dialog configuration which supersedes the faces navigation rules
- nice that you only have to define it in one place.
> 
> It looks like the dialog navigation handler intercepts certain requests based on a prefix
mapping.  However, the JSP commandButton action attributes seems to have action binding to
the view controller.

The navigation handler does not actually "intercept" a request ... it
is invoked after the application's action has returned.  The normal
scenario on a postback goes through the standard JSF lifecycle:
* Restore View
* Apply Request Values
* Process Validations
* Update Model Values
* Invoke Application -- the navigation hander is called AFTER this.
* Render Response

The DialogNavigationHandler implementation, then, operates in one of
three modes:

* Not currently executing a dialog, and outcome is not prefixed --
  delegates to the standard NH so that all the usual JSF navigation
  management works as expected.

* Not currently executing a dialog, and outcome is prefixed ("dialog:xxx") --
  causes the dialog to be entered, and starts executing states and transitions:
  * action state -- call the method and use the returned value to
drive transitions
  * subdialog state -- call the nested dialog and use the returned outcome
    to drive transitions
  * view state -- create a component tree for the specified view identifier,
    and return control to JSF (which will cause this page to be rendered).
    Upon the upcoming form submit, the following bullet will describe
what happens.

* Currently executing a dialog -- logically, the dialog got "suspended" in a
  view state, so that the interaction with the user can take place.  When the
  subsequent postback happens, it executes all the way through Invoke
  Application again.  And the logical outcome returned by the action associated
  with your submit button is what drives a transition to the next state.

The second scenario is a convenience that lets you do things like this
in a menu to start executing a dialog:

    <h:commandLink value="Log On" action="dialog:Log On"/>

that returns the static outcome "dialog:Log On" instead of invoking a
user action.  This, in turn, causes the "Log On" dialog to be entered.

Note that a particular page has no knowledge of whether it's being
executed in the context of a dialog or not -- its action methods just
return logical outcomes describing what happened.  The unique feature
is that the outcomes are interpreted differently inside or outside a
dialog -- and the same page can in fact be used either inside or
outside a dialog, or in more than one dialog, with no problems.

> Are these action methods fired on the ViewController or intercepted by the dialog navigation
handler? What's the glue between views that participate in a managed dialog verses those that
don't?

The ViewController functionality is orthogonal to the dialog
management.  It works like this:

* DialogNavigationHandler encounters a ViewState that specifies
  a view identifier of "/foo.jsp" to be requested.

* DialogNavigationHandler calls createView(context, "/foo.jsp") on
  the ViewHandler implementation for this application.

* Shale provides a custom ViewHandler whose createView() method
  does the extra event callback stuff (such as calling init()).

Thus, DialogNavigationHandler doesn't have to know anything about
ViewController.  Indeed, the current implementation of
"org.apache.shale.dialog" and its subordinate packages depends only on
JSF, not on anything specific to Shale -- other than loading the
configuration files.  It would work without Shale (although you'd find
yourself putting in more action states in between your view states, to
do what the prerender() method does for you).

> 
> > Craig
> >
> 
> Gary
> 
> 

Craig

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message