On 5/2/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
