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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to