Return-Path: Delivered-To: apmail-myfaces-users-archive@www.apache.org Received: (qmail 3334 invoked from network); 12 Sep 2007 19:47:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Sep 2007 19:47:36 -0000 Received: (qmail 3526 invoked by uid 500); 12 Sep 2007 19:47:24 -0000 Delivered-To: apmail-myfaces-users-archive@myfaces.apache.org Received: (qmail 3488 invoked by uid 500); 12 Sep 2007 19:47:24 -0000 Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Discussion" Delivered-To: mailing list users@myfaces.apache.org Received: (qmail 3477 invoked by uid 99); 12 Sep 2007 19:47:24 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Sep 2007 12:47:24 -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: local policy) Received: from [198.175.154.225] (HELO us194mx04.tycoelectronics.net) (198.175.154.225) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Sep 2007 19:47:19 +0000 Received: from us194mx11.tycoelectronics.net ([163.241.185.106]) by us194mx04.tycoelectronics.net with Microsoft SMTPSVC(6.0.3790.2499); Wed, 12 Sep 2007 15:46:53 -0400 Received: from us358mx02.tycoelectronics.net ([148.174.34.35]) by us194mx11.tycoelectronics.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 15:46:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F575.AA77DEC9" Subject: RE: Dialog issue during ADF->Trinidad migration Date: Wed, 12 Sep 2007 15:46:52 -0400 Message-ID: In-Reply-To: <6dac79b90709121106x5bff2ca1we3ab307964346f0b@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Dialog issue during ADF->Trinidad migration Thread-Index: Acf1daoeajSwpR5fTPS8sBP2B08LeA== References: <6dac79b90709121106x5bff2ca1we3ab307964346f0b@mail.gmail.com> From: "Bertrand, Shawn R" To: "Adam Winer" , "MyFaces Discussion" , "Matthias Wessendorf" X-OriginalArrivalTime: 12 Sep 2007 19:46:52.0913 (UTC) FILETIME=[AAD0AE10:01C7F575] X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F575.AA77DEC9 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Thanks, fellas. We did indeed have a *.faces mapping. We now use /faces and all is well! =20 All the best, =20 Shawn =20 =20 ________________________________ From: Adam Winer [mailto:awiner@gmail.com]=20 Sent: Wednesday, September 12, 2007 2:06 PM To: MyFaces Discussion Subject: Re: Dialog issue during ADF->Trinidad migration =20 Yeah, that sounds like the issue. Older versions of the RI, as well as MyFaces 1.2 don't support *.faces mappings well enough for this scenario (I haven't looked into why). =20 -- Adam =20 On 9/12/07, Matthias Wessendorf wrote: Is it possible, that you are using myfaces 1.2 ? and *.faces mapping ? try, /faces/* as your mapping On 9/12/07, Bertrand, Shawn R wrote: > > >=20 > > Thanks for the clarification. > > > > Unfortunately, it isn't working in Trinidad as it did in ADF Faces. > FredJSP.getRedirectURL generates a baseURL of > "/nas/__ADFv__.faces?_afPfm =3D497604ee&_t=3Dfred" and arguments > of {"_vir", "/jsp/SnmpSsMacDetail.jsp", "loc", "en-US", "_minWidth", > "_minHeight",}. The second argument is correct and that resource is=20 > definitely present in the deployed application. > > > > The separate browser window does appear as it used to but it contains an > HTTP 404 error with the description "The requested resource (/__ADFv__.jsp)=20 > is not available.". > > > > Thanks again, > > > > Shawn Bertrand > > Tyco Electronics Corporation > > > > > > ______________________________ __ > > > From: Adam Winer [mailto:awiner@gmail.com] > Sent: Tuesday, September 11, 2007 4:32 PM > To: MyFaces Discussion > Subject: Re: Dialog issue during ADF->Trinidad migration=20 > > > > > There's two separate flags here: > > - useWindow > - usePopup > > If useWindow is false, that means we navigate the whole page > to the dialog. Simple enough.=20 > > If useWindow is true, then we look at usePopup: if it's false, > we want to show the dialog in a new browser window. > We use FredJSP so that we have a frameset around the > dialog view, needed to make sure that context is not lost=20 > when you navigate within the dialog. > > If usePopup is true, we use a DHTML dialog. We don't > need FredJSP, since we're putting the dialog in an iframe, > and can directly navigate to the page.=20 > > Does this make sense? > > What you're describing - " uses the URL returned from FredJSP. > getRedirectURL" - is intentional (and was the way things > worked back in ADF, FWIW). What should be happening next=20 > is that a frameset gets generated where the frame's source > is the URL of the desired page - so your dialog does show up. > Is that not working? > > -- Adam > > >=20 > > On 9/11/07, Bertrand, Shawn R < > shawn.bertrand@tycoelectronics.com> wrote: > > > > (Trinidad 1.0.2 - build from July - the current one). > > > > I've migrated our application to use Trinidad, and see some PPR issues that=20 > are likely ours, but for the most part everything is working as expected. > Except.... > > > > We use the dialog framework extensively, and every time we attempt to > display one a popup appears but uses the URL returned from=20 > FredJSP.getRedirectURL. This happens because the code in CoreRenderKit, > when constructing a DialogRequest object, calls usePopupForDialog to > determine if the popup is supported. Why wouldn't the passed-in usePopup=20 > setting be used? Fortunately for me (at least for now), I added the > "org.apache.myfaces.trinidadinternal.renderkit.USE_DIALOG_POPUP" > context parameter to my web.xml and popups are now appearing (though they=20 > appear in a dhtml-looking layer instead of the traditional popup dialog > (probably a good thing). > > > > Note: the Trinidad demo doesn't seem to need this context parameter to > display dialogs. > > > > Thanks in advance, > > > > Shawn Bertrand > > Tyco Electronics Corporation > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org =20 ------_=_NextPart_001_01C7F575.AA77DEC9 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Thanks, fellas.  We did indeed = have a *.faces mapping.  We now use /faces and all is = well!

 

All the = best,

 

Shawn

 

 

From: Adam = Winer [mailto:awiner@gmail.com]
Sent: Wednesday, = September 12, 2007 2:06 PM
To: MyFaces = Discussion
Subject: Re: Dialog issue = during ADF->Trinidad = migration

 

Yeah, that sounds like the issue.  Older versions of the = RI,

as well as MyFaces 1.2 don't support *.faces mappings = well

enough for this scenario (I haven't looked into = why).

 

-- Adam

 

On 9/12/07, Matthias Wessendorf <matzew@apache.org> wrote:

Is it possible, that you are
using myfaces 1.2 ?

and *.faces mapping ?
try, /faces/* as your mapping

On 9/12/07, Bertrand, Shawn R <shawn.bertrand@tycoelectronics.com> = wrote:
>
>
>
>
> Thanks for the clarification.
>
>
>
> Unfortunately, it isn't working in Trinidad as it did in ADF Faces.
> FredJSP.getRedirectURL generates a baseURL of
> "/nas/__ADFv__.faces?_afPfm =3D497604ee&_t=3Dfred" = and arguments
> of {"_vir", "/jsp/SnmpSsMacDetail.jsp", "loc", "en-US", "_minWidth",
> "_minHeight",}.  The second argument is correct = and that resource is
> definitely present in the deployed application.
>
>
>
> The separate browser window does appear as it used to but it = contains an
> HTTP 404 error with the description "The requested resource (/__ADFv__.jsp)
> is not available.".
>
>
>
> Thanks again,
>
>
>
> Shawn Bertrand
>
> Tyco Electronics Corporation
>
>
>
>
>
>  ______________________________ __
>
>
> From: Adam Winer [mailto:awiner@gmail.com]
>  Sent: Tuesday, September 11, 2007 4:32 PM
>  To: MyFaces Discussion
>  Subject: Re: Dialog issue during ADF->Trinidad migration
>
>
>
>
> There's two separate flags here:
>
>  - useWindow
>  - usePopup
>
>  If useWindow is false, that means we navigate the whole = page
>  to the dialog.  Simple enough.
>
>  If useWindow is true, then we look at = usePopup:  if it's false,
>  we want to show the dialog in a new browser window.
>  We use FredJSP so that we have a frameset around the
>  dialog view, needed to make sure that context is not = lost
>  when you navigate within the dialog.
>
>  If usePopup is true, we use a DHTML = dialog.  We don't
>  need FredJSP, since we're putting the dialog in an = iframe,
>  and can directly navigate to the page.
>
>  Does this make sense?
>
>  What you're describing - " uses the URL returned = from FredJSP.
>  getRedirectURL" - is intentional (and was the way = things
>  worked back in ADF, FWIW).  What should be = happening next
>  is that a frameset gets generated where the frame's = source
>  is the URL of the desired page - so your dialog does = show up.
>  Is that not working?
>
>  -- Adam
>
>
>
>
> On 9/11/07, Bertrand, Shawn R <
> shawn.bertrand@tycoelectronics.com> wrote:
>
>
>
> (Trinidad 1.0.2 – build = from July – the current one).
>
>
>
> I've migrated our application to use Trinidad, and see some PPR issues that
> are likely ours, but for the most part everything is working as = expected.
> Except….
>
>
>
> We use the dialog framework extensively, and every time we attempt = to
> display one a popup appears but uses the URL returned from
> FredJSP.getRedirectURL.  This happens because the code in CoreRenderKit,
> when constructing a DialogRequest object, calls usePopupForDialog = to
> determine if the popup is supported.  Why wouldn't the = passed-in usePopup
> setting be used?  Fortunately for me (at least for now), = I added the
> = "org.apache.myfaces.trinidadinternal.renderkit.USE_DIALOG_POPUP"= ;
> context parameter to my web.xml and popups are now appearing = (though they
> appear in a dhtml-looking layer instead of the traditional popup = dialog
> (probably a good thing).
>
>
>
> Note: the Trinidad demo doesn't = seem to need this context parameter to
> display dialogs.
>
>
>
> Thanks in advance,
>
>
>
> Shawn Bertrand
>
> Tyco Electronics Corporation
>
>


--
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpres= s.com/
mail: matzew-at-apache-dot-org

 

------_=_NextPart_001_01C7F575.AA77DEC9--