Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 88435 invoked from network); 1 Aug 2007 21:32:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 Aug 2007 21:32:53 -0000 Received: (qmail 9047 invoked by uid 500); 1 Aug 2007 21:32:52 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 9001 invoked by uid 500); 1 Aug 2007 21:32:51 -0000 Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Development" Delivered-To: mailing list dev@myfaces.apache.org Received: (qmail 8990 invoked by uid 99); 1 Aug 2007 21:32:51 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Aug 2007 14:32:51 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of simon.lessard.3@gmail.com designates 209.85.198.190 as permitted sender) Received: from [209.85.198.190] (HELO rv-out-0910.google.com) (209.85.198.190) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Aug 2007 21:32:38 +0000 Received: by rv-out-0910.google.com with SMTP id c27so217735rvf for ; Wed, 01 Aug 2007 14:32:23 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=bPPo22BGVV1uVu4Du7wGWnM4ZLjvJMQ35ibHgM5rJIXgED5dYQ5WM5yTbSp45i7ujT+bt8XXmJlwcgbeyn5qEAU78n2BK01y64AhC4eZ/VWkb6vfOGP+9nzN6YgWdTfFw9gRF7I0GxUnckHCycY1LET9enVj6jKO5fVegfn6Dy8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=L8gvC9/UT6uQOpoyHD0++6S5NqVhuJMP3nye1LgaZkmlqMwNgNms31+gY/OcnxHur10SKpOGW90YfsnI9eldFtlcVYBK09cJJKi1GJ3+M+tiejHbzE6PaZI85bxQm5J7+5nMjSWnO4/AUhW/Q3xnr/ssQaKvnI7wzEpK6/KJX/0= Received: by 10.115.89.1 with SMTP id r1mr1147152wal.1186003943447; Wed, 01 Aug 2007 14:32:23 -0700 (PDT) Received: by 10.114.152.7 with HTTP; Wed, 1 Aug 2007 14:32:23 -0700 (PDT) Message-ID: <254acf980708011432s20655f99lb18ce31e60ba5e3c@mail.gmail.com> Date: Wed, 1 Aug 2007 17:32:23 -0400 From: "Simon Lessard" To: "MyFaces Development" Subject: Re: [Trinidad] Navigate to different view on return from dialog In-Reply-To: <7F48470F8BE0AC488F0000539350728902400C5A@zeus.chordiant.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_52047_23582220.1186003943405" References: <7F48470F8BE0AC488F0000539350728902400C18@zeus.chordiant.com> <6dac79b90708011418n1e8beedam7800ce2cb6af7db4@mail.gmail.com> <7F48470F8BE0AC488F0000539350728902400C5A@zeus.chordiant.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_52047_23582220.1186003943405 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 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 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. > ------=_Part_52047_23582220.1186003943405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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.

------=_Part_52047_23582220.1186003943405--