You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shale.apache.org by Sean Schofield <se...@gmail.com> on 2006/09/05 19:51:47 UTC
[dialog] Revisiting one dialog per JSF view
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.
Lets think of what not fixing this would imply. Should you really
have to hit a "Cancel" button inside the dialog in order for your "my
account" link to work properly? What if the user wants to stop
checking out and look at their account? Do you stop showing all links
and buttons on the screen just because you are now "in a dialog?" If
you treat the dialog as a special multi-step view, and not as a modal
popup, then the user should be able to click around the webapp just
like they could before the developer decided to use a shale dialog.
Taking this one step further ... lets assume we're ok with fixing
SHALE-276. If the user has effectively canceled the "Checkout"
dialog, by clicking on a non dialog related commandLink. What happens
when the user clicks on a second dialog, lets say "My Account"? I'm
assuming here that both dialogs are launched from the same view.
Right now our scheme thinks that you want the "Checkout" dialog
because that was what was last stored in the view. But you really
want the MyAccount dialog.
I'm not sure how we solve this last problem but its definitely a problem.
Sean
Re: [dialog] Revisiting one dialog per JSF view
Posted by Craig McClanahan <cr...@apache.org>.
On 9/12/06, Sean Schofield <se...@gmail.com> wrote:
>
> This looks good. Sorry I haven't responded sooner but I'm in another
> busy patch with my day job.
>
> What about a convenience method for cancelling the dialog as well?
Great minds think alike :-). See DialogContext.stop().
Sean
Craig
On 9/11/06, Craig McClanahan <cr...@apache.org> wrote:
> > On 9/11/06, Craig McClanahan <cr...@apache.org> wrote:
> > >
> > >
> > > 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;
> > >
> > > }
> > >
> >
> >
> > OK, I've addressed the verbosity of programmatically starting a new
> dialog.
> > The programmatic start and navigate now collapses to:
> >
> > // Create and start the "CheckOut" dialog
> > dcontext = manager.create(context, "CheckOut");
> > dcontext.start(context);
> > return null;
> >
> > We should consider pushing the actual navigation on an ongoing
> DialogContext
> > instance to inside the advance() method as well, although in practice
> that
> > would only simplify a bit of logic inside Dialog2NavigationHandler, not
> any
> > application level code.
> >
> > Craig
> >
> >
>
Re: [dialog] Revisiting one dialog per JSF view
Posted by Sean Schofield <se...@gmail.com>.
This looks good. Sorry I haven't responded sooner but I'm in another
busy patch with my day job.
What about a convenience method for cancelling the dialog as well?
Sean
On 9/11/06, Craig McClanahan <cr...@apache.org> wrote:
> On 9/11/06, Craig McClanahan <cr...@apache.org> wrote:
> >
> >
> > 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;
> >
> > }
> >
>
>
> OK, I've addressed the verbosity of programmatically starting a new dialog.
> The programmatic start and navigate now collapses to:
>
> // Create and start the "CheckOut" dialog
> dcontext = manager.create(context, "CheckOut");
> dcontext.start(context);
> return null;
>
> We should consider pushing the actual navigation on an ongoing DialogContext
> instance to inside the advance() method as well, although in practice that
> would only simplify a bit of logic inside Dialog2NavigationHandler, not any
> application level code.
>
> Craig
>
>
Re: [dialog] Revisiting one dialog per JSF view
Posted by Craig McClanahan <cr...@apache.org>.
On 9/11/06, Craig McClanahan <cr...@apache.org> wrote:
>
>
> 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;
>
> }
>
OK, I've addressed the verbosity of programmatically starting a new dialog.
The programmatic start and navigate now collapses to:
// Create and start the "CheckOut" dialog
dcontext = manager.create(context, "CheckOut");
dcontext.start(context);
return null;
We should consider pushing the actual navigation on an ongoing DialogContext
instance to inside the advance() method as well, although in practice that
would only simplify a bit of logic inside Dialog2NavigationHandler, not any
application level code.
Craig
Re: [dialog] Revisiting one dialog per JSF view
Posted by Craig McClanahan <cr...@apache.org>.
On 9/5/06, David Geary <sa...@gmail.com> wrote:
>
> 2006/9/5, Sean Schofield <se...@gmail.com>:
> >
> > 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
> >
>
>
Re: [dialog] Revisiting one dialog per JSF view
Posted by David Geary <sa...@gmail.com>.
2006/9/5, Sean Schofield <se...@gmail.com>:
>
> 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.
david
Sean
>