[PORTAL] Launch Parameters

[Scott O'Bryan <da...@gmail.com>]

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

Re: Re: [PORTAL] Launch Parameters

[Adam Winer <aw...@gmail.com>]

It's two lifecycles on *two different pages*, where the
results of the first affect the second...  Can't be done
together.

-- Adam

On 12/13/06, Scott O'Bryan <da...@gmail.com> wrote:
> 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 <da...@gmail.com> 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
> >>>
> >>
> >
> >
>
>

Re: [PORTAL] Launch Parameters

[Scott O'Bryan <da...@gmail.com>]

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 <da...@gmail.com> 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
>>>
>>
>
>

Re: [PORTAL] Launch Parameters

[Scott O'Bryan <da...@gmail.com>]

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 <da...@gmail.com> 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
>>
>

Re: [PORTAL] Launch Parameters

[Adam Winer <aw...@gmail.com>]

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 <da...@gmail.com> 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
>