Issue Details (XML | Word | Printable)

Key: PORTLETSPEC3-25
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Minor Minor
Assignee: Neil Griffin
Reporter: msnicklous
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
portletspec3

Errata: Clarify when & how parameters are removed

Created: 15/May/13 12:11 PM   Updated: 05/Aug/13 09:50 PM   Resolved: 26/Jul/13 12:49 PM
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

Tags:
Participants: msnicklous and Neil Griffin


 Description  « Hide

This issue was split off from "PORTLETSPEC3-8 Errata: Clarify inconsistencies regarding getting and setting parameters"

  1. Under which cases (if any) should setting a parameter to a value of null remove the parameter?
  2. In which cases are public render parameters removed?


Neil Griffin added a comment - 15/May/13 09:58 PM

Under which cases (if any) should setting a parameter to a value of null remove the parameter?

In both Pluto and Liferay, calling StateAwareResponse.setRenderParameter("paramName", (String) null) causes an IllegalArgumentException to be thrown, even though the JavaDocs for StateAwareResponse.setRenderParameter(String name, String value)

So with these two portlet containers, the only way remove a private render parameter (from the request map) is to remove ALL of them by calling StateAwareResponse.setRenderParameters(Map) with an empty map.

In which cases are public render parameters removed?

In Pluto and Liferay, the only way to remove a public render parameter (from the request map) is by calling StateAwareResponse.removePublicRenderParameter(String) or by removing ALL public and private by calling StateAwareResponse.setRenderParameters(Map) with an empty map.


Neil Griffin added a comment - 15/May/13 11:01 PM

I did some additional testing, and in both Pluto and Liferay, calling StateAwareResponse.setRenderParameter("publicRenderParameter", "") works, and actually REMOVES the public render parameter from the maps. I believe that this is the expectation that Julien had during our 14 May conference call.

On Pluto, calling StateAwareResponse.setRenderParameter("privateRenderParameter", "") REMOVES the private render parameter from the maps.

On Liferay, calling StateAwareResponse.setRenderParameter("privateRenderParameter", "") sets the underlying map value to new String[] {""}

Also during our 14 May conference call, I mentioned that JSF has a web.xml context-param feature named javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL that permits empty string request parameter values.

I don't think that any of the proposed changes would cause a problem. In general, we just need to make sure that we don't introduce incompatibilities with this JSF feature.


msnicklous added a comment - 19/Jul/13 08:47 AM

WebSphere works like Liferay does - a null string ("") is allowed.

The Pluto behavior of removing a parameter by setting it to the null string is not described in the spec anywhere, while removing a parameter by setting it to null is described in the javadocs for StateAwareResponse.setRenderParameter(String name, String value).

I believe that a null string ("") should be allowed as a valid parameter value, while setting a private parameter to null should remove the parameter.

Public render parameters may be set through the setParameter and setRenderParameter calls, but they may not be removed by setting them to null. To remove a public render parameter, the removePublicRenderParameter method must be used.


Neil Griffin added a comment - 23/Jul/13 03:27 PM

+1 This would mean that with both Pluto and Liferay, calling StateAwareResponse.setRenderParameter("paramName", (String) null) should not cause IllegalArgumentException to be thrown, but rather that the parameter should be removed.


msnicklous added a comment - 26/Jul/13 12:49 PM

reworked apidocs for the set parameter methods on BaseURL and StateAwareResponse.


msnicklous added a comment - 02/Aug/13 08:38 AM

reviewed on 20130730 and can be closed.


Neil Griffin added a comment - 05/Aug/13 09:46 PM

Neil Griffin added a comment - 05/Aug/13 09:50 PM

Please disregard my previous comment. I see the changes there now. Thanks Scott.