myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Marinschek" <martin.marinsc...@gmail.com>
Subject Re: [Trinidad] Navigate to different view on return from dialog
Date Wed, 01 Aug 2007 22:44:18 GMT
You might want to look at the Redirect-Tracker in MyFaces for inspiration.

regards,

Martin

On 8/1/07, Simon Lessard <simon.lessard.3@gmail.com> wrote:
> 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.
> >
>
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Mime
View raw message