On 9/5/06, David Geary <[EMAIL PROTECTED]> wrote:
2006/9/5, Sean Schofield <[EMAIL PROTECTED]>:
>
> We might want to revisit the one dialog per JSF view assumption. I'm
> playing with the new stuff in shale-petstore and I have run into some
> unexpected behavior. I have a commandLink that kicks off a "checkout"
> dialog. This command link is located in a "menu" bar that is
> displayed on every page using a facelets layout scheme (for those not
> familiar with facelets, the reusable layouts are similar to Tiles.)
>
> Lets suppose there are a few more "menu" options, such as logout, my
> account, etc. I've already made the argument that you should be able
> to "cancel" the dialog by clicking som other command link in the menu
> that has nothing to do with the dialog outcomes (SHALE-276). While
> this might be a PITA to support, its pretty common in a webapp to want
> to click on something else on the screen other then the previous, next
> buttons of your dialog. IMO, the expected behavior would be that the
> dialog stops and the new view is loaded.
One way or another, we've got to support non-dialog outcomes during the
course of a dialog. Halting the dialog seems to make sense, but of course,
there will be users that link out of a dialog and then hit the back button
expecting to be back in the dialog.
Cancelling the current dialog is also quite easy with the current APIs. To
do Sean's "checkout menu option should cancel the current dialog and start
the checkout dialog", you can do something like this in the checkout
button's action:
public String checkout() {
// Cancel the current dialog (if any, whatever it is)
FacesContext context = FacesContext.getCurrentInstance();
DialogContextManager manager = (DialogContextManager)
context.getApplication().getVariableResolver().resolveVariable(
Constants.MANAGER_BEAN);
DialogContext dcontext = (DialogContext)
context.getApplication().getVariableResolver().resolveVariable(
Constants.CONTEXT_BEAN);
if (dcontext != null) {
manager.remove(dcontext);
}
// Programmatically start the "CheckOut" dialog and advance
// it to the point where it needs to display a view
dcontext = manager.create(context, "CheckOut");
String viewId = dcontext.advance(context, null);
// Navigate to the requested view
ViewHandler vh = context.getApplication().getViewHandler();
UIViewRoot view = vh.createView(context, viewId);
view.setViewId(viewId);
context.setViewRoot(view);
context.renderResponse();
return null;
}
The verbosity of programmatically starting a dialog is a usability challenge
we should probably address with some helper methods somewhere, but the use
case stated in Sean's initial message can certainly be handled. Note that
you don't even *have* to explicitly start a dialog if you just want normal
JSF navigation to handle what comes next. Once you've cancelled the current
dialog, normal JSF navigation rules will apply because the dialog2 custom
navigation handler will say "aha, there is no active dialog, so just
delegate to the standard navigation handler and return."
Craig
david
Sean
>
