myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Lessard" <simon.lessar...@gmail.com>
Subject Re: [Trinidad] Navigate to different view on return from dialog
Date Wed, 01 Aug 2007 21:32:23 GMT
Hello both of you,

We might have to deal with that redirect automatically even with
NavigationHandler though. We had the issue recently in a project where we
were losing our hidden parameters because of that, resulting in some nasty
effect that could only be solved by forcing the user to accept a change in
the application behavior (never the best looking solution).


Regards,

~ Simon

On 8/1/07, David Brunette <David.Brunette@chordiant.com> wrote:
>
>
>      Oh, OK.  Thanks Adam.  I thought the sendRedirect() might have been
> required because it was a partial submit.
>
>      But what about the thoughts around separating the launching of a
> dialog from the actual action of the button?  With the way that I would
> like to use the dialog, it seems cleaner to have the application's code
> in the action method instead of pushing it off to the returnListener of
> the dialog.
>
> Dave
>
> -----Original Message-----
> From: Adam Winer [mailto:awiner@gmail.com]
> Sent: Wednesday, August 01, 2007 5:19 PM
> To: MyFaces Development
> Subject: Re: [Trinidad] Navigate to different view on return from dialog
>
> David,
>
> Instead of calling sendRedirect(), in your return listener
> you could simply get the NavigatioHandler and invoke it
> directly:
>
>   nh.handleNavigation(context, null, "afterDialogOutcome");
>
> ... and any navigation rule attached to that outcome will happily
> fire, redirect or no (it'll get turned into a redirect automatically).
>
> -- Adam
>
>
> On 8/1/07, David Brunette <David.Brunette@chordiant.com> wrote:
> >
> >
> >
> >
> >      Hi everybody.
> >
> >
> >
> >      There has been a post recently regarding "[Trinidad] page refresh
> on
> > return from a dialog".  I have a similar problem that I am trying to
> > solve... but since I am looking for something slightly different than
> just
> > refreshing the same page, I am starting a different post so I don't
> hault
> > the other useful discussion.
> >
> >
> >
> >      As the Dialog Framework works now, you can trigger a
> partialSubmit on
> > return from a dialog.  This allows you to partially update certain
> values on
> > the main page when closing the dialog.  This works great for me.  But
> there
> > are instances when I'd like to use a dialog and then trigger a FULL
> submit
> > on return from the dialog... which could, and normally would, result
> in
> > navigation to a different view.
> >
> >
> >
> >      To be more specific about what I am trying to do... I'd like to
> have a
> > Confirmation Dialog shown for a button before the action method for
> that
> > button actually gets called (a sort of "Are you sure?  OK/Cancel"
> dialog).
> > Thinking through some options...  As it stands now, the dialog can be
> > thought of as the actual action of a particular button (since you
> would
> > write something like action="dialog:someRelatedWork").
> > What I'm trying to do is separate the dialog from the action of the
> button.
> > I've started to lean towards a new attribute on the command component
> called
> > "confirmationAction".  OK, it may not be the greatest name for the
> > attribute, but my point is to try to have a way to show a dialog for
> that
> > button BEFORE executing the action for that button, which would then
> be
> > automatically called on return from that dialog (with either a full or
> > partial submit as specified by the regular "partialSubmit" attribute).
> >
> >
> >
> >      I suppose we could do a little trickery in the returnListener to
> do
> > some the work, call the ViewHandler directly to get the URL of the new
> view,
> > and then use SendRedirect()... but is that really the best answer of
> how to
> > accomplish something like this?  I have also seen some suggestions
> about
> > using a JS alert() for this sort of thing, but I'd prefer to stay away
> from
> > using alerts like this in our app.
> >
> >
> >
> >      I'm interested in any thoughts on "confirmationAction"
> approach... or
> > possible solutions to accomplish what I'm trying to do.  Thanks...
> >
> >
> >
> > Dave
> > The information transmitted herewith is sensitive information of
> Chordiant
> > Software or its customers and is intended only for use to the
> individual or
> > entity to which it is addressed. If the reader of this message is not
> the
> > intended recipient, you are hereby notified that any review,
> retransmission,
> > dissemination, distribution, copying or other use of, or taking of any
> > action in reliance upon, this information is strictly prohibited. If
> you
> > have received this communication in error, please contact the sender
> and
> > delete the material from your computer.
> The information transmitted herewith is sensitive      information of
> Chordiant Software or its customers and is intended only for use to the
> individual or entity to which it is addressed. If the reader of this message
> is not the intended recipient, you are hereby notified that any review,
> retransmission, dissemination, distribution, copying or other use of, or
> taking of any action in reliance upon, this information is strictly
> prohibited. If you have received this communication in error, please contact
> the sender and delete the material from your computer.
>

Mime
View raw message