You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by Eric Dalquist <er...@doit.wisc.edu> on 2008/01/03 15:47:50 UTC
ActionResponseImpl and Null Render Parameters
ActionResponseImpl does exactly what the Javadoc says with render
parameter validation. The problem is the Javadoc is inconsistent,
setRenderParameter(String, String) says neither the name or value can be
null but setRenderParameters(String, String[]) and
setRenderParameters(Map) just state that neither the key or values
String[] can be null. With this documentation having a null value for a
parameter is possible simply by calling setRenderParameters("foo", new
String[] { null }). Is this valid and if so how should it be encoded in
the URL? Should additional checks be added to the setRenderParameters
methods to check for null values in the String[]?
-Eric
Re: ActionResponseImpl and Null Render Parameters
Posted by Eric Dalquist <er...@doit.wisc.edu>.
I also discovered that the pluto testsuite actually sets a null value
for a render parameter as part of its expected behavior. I updated our
portlet URL generation code to treat null values as an empty string.
-Eric
Elliot Metsger wrote:
>
> Eric Dalquist wrote:
>> ActionResponseImpl does exactly what the Javadoc says with render
>> parameter validation. The problem is the Javadoc is inconsistent,
>> setRenderParameter(String, String) says neither the name or value can
>> be null but setRenderParameters(String, String[]) and
>> setRenderParameters(Map) just state that neither the key or values
>> String[] can be null. With this documentation having a null value for
>> a parameter is possible simply by calling setRenderParameters("foo",
>> new String[] { null }). Is this valid and if so how should it be
>> encoded in the URL? Should additional checks be added to the
>> setRenderParameters methods to check for null values in the String[]?
>
> It looks like in the 286 proposed final draft, setRenderParameter(
> String, String ) has been changed to allow a null value. The doc for
> setRenderParameter( String, String[] ) and setRenderParameter(
> Map<String[]>) seem consistent with 168.
>
> So if null is allowed we have to figure the encoding as you say (the
> 286 codebase may lend an idea). Can we start to allow a null
> parameter without unintended side affects?
>
> E
Re: ActionResponseImpl and Null Render Parameters
Posted by Elliot Metsger <em...@jhu.edu>.
This is an issue in the 286 codebase (I'm looking at the
1.1-286-trunk-merge brance) as well:
StateAwareResponseImpl setRenderParameter( String, String ) doesn't
allow a null value.
Elliot Metsger wrote:
>
> Eric Dalquist wrote:
>> ActionResponseImpl does exactly what the Javadoc says with render
>> parameter validation. The problem is the Javadoc is inconsistent,
>> setRenderParameter(String, String) says neither the name or value can
>> be null but setRenderParameters(String, String[]) and
>> setRenderParameters(Map) just state that neither the key or values
>> String[] can be null. With this documentation having a null value for
>> a parameter is possible simply by calling setRenderParameters("foo",
>> new String[] { null }). Is this valid and if so how should it be
>> encoded in the URL? Should additional checks be added to the
>> setRenderParameters methods to check for null values in the String[]?
>
> It looks like in the 286 proposed final draft, setRenderParameter(
> String, String ) has been changed to allow a null value. The doc for
> setRenderParameter( String, String[] ) and setRenderParameter(
> Map<String[]>) seem consistent with 168.
>
> So if null is allowed we have to figure the encoding as you say (the 286
> codebase may lend an idea). Can we start to allow a null parameter
> without unintended side affects?
>
> E
Re: ActionResponseImpl and Null Render Parameters
Posted by Elliot Metsger <em...@jhu.edu>.
Eric Dalquist wrote:
> ActionResponseImpl does exactly what the Javadoc says with render
> parameter validation. The problem is the Javadoc is inconsistent,
> setRenderParameter(String, String) says neither the name or value can be
> null but setRenderParameters(String, String[]) and
> setRenderParameters(Map) just state that neither the key or values
> String[] can be null. With this documentation having a null value for a
> parameter is possible simply by calling setRenderParameters("foo", new
> String[] { null }). Is this valid and if so how should it be encoded in
> the URL? Should additional checks be added to the setRenderParameters
> methods to check for null values in the String[]?
It looks like in the 286 proposed final draft, setRenderParameter(
String, String ) has been changed to allow a null value. The doc for
setRenderParameter( String, String[] ) and setRenderParameter(
Map<String[]>) seem consistent with 168.
So if null is allowed we have to figure the encoding as you say (the 286
codebase may lend an idea). Can we start to allow a null parameter
without unintended side affects?
E