From adffaces-dev-return-1837-apmail-incubator-adffaces-dev-archive=incubator.apache.org@incubator.apache.org Wed Dec 13 21:08:21 2006 Return-Path: Delivered-To: apmail-incubator-adffaces-dev-archive@locus.apache.org Received: (qmail 36815 invoked from network); 13 Dec 2006 21:08:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Dec 2006 21:08:21 -0000 Received: (qmail 68551 invoked by uid 500); 13 Dec 2006 21:08:28 -0000 Delivered-To: apmail-incubator-adffaces-dev-archive@incubator.apache.org Received: (qmail 68539 invoked by uid 500); 13 Dec 2006 21:08:28 -0000 Mailing-List: contact adffaces-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: adffaces-dev@incubator.apache.org Delivered-To: mailing list adffaces-dev@incubator.apache.org Received: (qmail 68530 invoked by uid 99); 13 Dec 2006 21:08:28 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Dec 2006 13:08:28 -0800 X-ASF-Spam-Status: No, hits=1.4 required=10.0 tests=SPF_NEUTRAL,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: 141.146.126.228 is neither permitted nor denied by domain of darkarena@gmail.com) Received: from [141.146.126.228] (HELO agminet01.oracle.com) (141.146.126.228) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Dec 2006 13:08:17 -0800 Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id kBDL7rto005046; Wed, 13 Dec 2006 15:07:53 -0600 Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id kBDGdkME024065; Wed, 13 Dec 2006 14:07:48 -0700 Received: from sobryan-lap.us.oracle.com by rcsmt251.oracle.com with ESMTP id 2288693021166044043; Wed, 13 Dec 2006 14:07:23 -0700 Message-ID: <45806B88.4030208@gmail.com> Date: Wed, 13 Dec 2006 14:07:20 -0700 From: "Scott O'Bryan" User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Scott O'Bryan" CC: adffaces-dev@incubator.apache.org Subject: Re: [PORTAL] Launch Parameters References: <45803C1E.4000006@gmail.com> <6dac79b90612131216s5bf16ad2k78f93524daf3ec10@mail.gmail.com> <45806AFE.4080302@gmail.com> In-Reply-To: <45806AFE.4080302@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-Virus-Checked: Checked by ClamAV on apache.org One more question then. Does this run two different lifecycles (ie. the dialog one runs and returns, then the base one is executed) or is there a possibility of cramming these into one lifecycle call? Scott Scott O'Bryan wrote: > Interesting. I see your point. > > Adam Winer wrote: >> This is part of the dialog framework, for returning >> from a dialog shown in-place (instead of in a popup >> window). >> >> I think it'd be very tough to make this a redirect, >> since there can be *a lot* of parameters (it's basically >> a full POST), and they won't all fit in a GET. >> >> -- Adam >> >> >> On 12/13/06, Scott O'Bryan wrote: >>> Hello everyone, >>> >>> I'm looking at supporting "launch parameters" for the Portal in >>> Trinidad. To recap my understanding of them, in the TrinidadFilter, >>> Trinidad does its filter stuff and then does a doFilter on the >>> FilterChain. When the chain returns, the TrinidadFilter checks for the >>> existence of LaunchParameters and, if they exist, it essentially >>> executes the doFilter again with a modified set of parameters (and thus >>> runs the Lifecycle again). >>> >>> In Portlets we really don't have this capability because this is really >>> controlled by the bridge right now and it is unlikely we'll be able to >>> support this without specific enhancements to the Bridge until JSR-286. >>> So my question is, would I be able to "simulate" this behavior in a >>> portal environment by sending a redirect back to the portlet with the >>> new parameters? I know that this will cause performance issues in the >>> short term, but it will do so only in a Portal environment and then >>> only >>> until filters are supported in a portal environment. >>> >>> I'm simply not sure how these are used, exactly, which is why I'm >>> asking >>> if the redirect would be functionally equivalent. >>> >>> Scott >>> >> > >