Following up again on encoded parameters in portlet URLs

[Tim Kettering <ti...@vivakos.com>]

I sent out an email about the Pluto portal driver encoding parameters from
the Response object into the URLs that are returned to the user.  I did not
receive any reply on this from anyone, and I am going to throw out this one
last email in the hopes that someone will reply.  Further discussion w/
another developer, John Lewis, he wrote his reasoning below:

<begin quote>
When you look at the spec, you'll see that all the discussion of render
parameters is in PLT.11.1.1 and PLT.12.2.3.  There is no discussion of how
the process of passing render parameters via the ActionResponse to the
RenderRequest should be implemented -- that is left up to the developers
implementing the spec.

The closest thing to this topic is a statement in PLT.12.2.3 that "Portlet
developers do not need to 'x-www-form-urlencoded' encode render parameters
names and values set in the ActionResponse."  This means that it is the
portlet-container's responsibility to faithfully deliver these String
parameters from the ActionResponse to the RenderRequest.  However, there is
no discussion on any limitation of number, size, or content of the Strings.

I think your example makes it even clearer that this is a Pluto bug.  There
is no reason that we should not be able to pass a large String (containing
HTML or plain text or whatever) forward from the action phase to the render
phase as a render parameter.  There is certainly nothing in the spec to
discourage this.
</end quote>

So, can some developer please comment on this.  Thank you.

-tim

Re: Following up again on encoded parameters in portlet URLs

[David Barral <da...@elrincondelprogramador.com>]

Hi.
I also think that mantaining the parameters through the URLs it's a 
mistake because in a real portal you could easily overflow the server 
url buffer (for instance tomcat had a limited buffer, maybe it was 2k 
long but I don't remenber well). In the project I'm working on we 
mantain the portlet state in the session (with alll the performance 
issues that this can have).

Another solution we brought up along the development was to use a hidden 
form field (similar to the .NET ViewState) that mantained the state. The 
problem here is the need to send taht field to the server every time the 
user clicks on a link, form button. Even if we put together all the 
necessary pieces to make it work we would still suffer bandwith loss and 
delays (encoding and decoding the field).

We have considered anoter posibilities but not seriously enough to 
mention them.

Hope this helps.
Regards.
David

Tim Kettering wrote:
> I sent out an email about the Pluto portal driver encoding parameters from
> the Response object into the URLs that are returned to the user.  I did not
> receive any reply on this from anyone, and I am going to throw out this one
> last email in the hopes that someone will reply.  Further discussion w/
> another developer, John Lewis, he wrote his reasoning below:
> 
> <begin quote>
> When you look at the spec, you'll see that all the discussion of render
> parameters is in PLT.11.1.1 and PLT.12.2.3.  There is no discussion of how
> the process of passing render parameters via the ActionResponse to the
> RenderRequest should be implemented -- that is left up to the developers
> implementing the spec.
> 
> The closest thing to this topic is a statement in PLT.12.2.3 that "Portlet
> developers do not need to 'x-www-form-urlencoded' encode render parameters
> names and values set in the ActionResponse."  This means that it is the
> portlet-container's responsibility to faithfully deliver these String
> parameters from the ActionResponse to the RenderRequest.  However, there is
> no discussion on any limitation of number, size, or content of the Strings.
> 
> I think your example makes it even clearer that this is a Pluto bug.  There
> is no reason that we should not be able to pass a large String (containing
> HTML or plain text or whatever) forward from the action phase to the render
> phase as a render parameter.  There is certainly nothing in the spec to
> discourage this.
> </end quote>
> 
> So, can some developer please comment on this.  Thank you.
> 
> -tim
> 
> 

-- 
/**
  * David Barral
  * El Rincón del programador [http://www.elrincondelprogramador.com]
  * david@elrincondelprogramador.com
  */

Re: Following up again on encoded parameters in portlet URLs

["David H. DeWolf" <dd...@apache.org>]

Tim,

Sorry I haven't had a chance to take a look at this yet.  The first 
thing that comes to mind is that it's possible that your parameters are 
being truncated because you are blowing the url buffer -- especially 
since it sounds like you're embedding a bit of html in the parameters.

Do you have a simple test case that duplicates this error so that I can 
research it a little more.

David

Tim Kettering wrote:
> I sent out an email about the Pluto portal driver encoding parameters from
> the Response object into the URLs that are returned to the user.  I did not
> receive any reply on this from anyone, and I am going to throw out this one
> last email in the hopes that someone will reply.  Further discussion w/
> another developer, John Lewis, he wrote his reasoning below:
> 
> <begin quote>
> When you look at the spec, you'll see that all the discussion of render
> parameters is in PLT.11.1.1 and PLT.12.2.3.  There is no discussion of how
> the process of passing render parameters via the ActionResponse to the
> RenderRequest should be implemented -- that is left up to the developers
> implementing the spec.
> 
> The closest thing to this topic is a statement in PLT.12.2.3 that "Portlet
> developers do not need to 'x-www-form-urlencoded' encode render parameters
> names and values set in the ActionResponse."  This means that it is the
> portlet-container's responsibility to faithfully deliver these String
> parameters from the ActionResponse to the RenderRequest.  However, there is
> no discussion on any limitation of number, size, or content of the Strings.
> 
> I think your example makes it even clearer that this is a Pluto bug.  There
> is no reason that we should not be able to pass a large String (containing
> HTML or plain text or whatever) forward from the action phase to the render
> phase as a render parameter.  There is certainly nothing in the spec to
> discourage this.
> </end quote>
> 
> So, can some developer please comment on this.  Thank you.
> 
> -tim
> 
>