Skip to main content

[JIRA] Commented: (PORTLETSPEC3-8) Errata: Clarify inconsistencies regarding getting and setting parameters

  • From: "andre.hagemeier (JIRA)" < >
  • To:
  • Subject: [JIRA] Commented: (PORTLETSPEC3-8) Errata: Clarify inconsistencies regarding getting and setting parameters
  • Date: Wed, 31 Jul 2013 17:08:34 +0000 (UTC)
  • Auto-submitted: auto-generated


    [ 
https://java.net/jira/browse/PORTLETSPEC3-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=367016#action_367016
 ] 

andre.hagemeier commented on PORTLETSPEC3-8:
--------------------------------------------

Neil,
"Regarding #6, I checked the Liferay and Pluto source code, and neither 
return an immutable map. It is possible that portlet developers have been 
calling BaseURL.getParameterMap().put(name, value) in order to set values, 
and changing to an immutable map would cause legacy applications to be 
non-backward-compatible."

I have seen this being done, and I have done it personally. E.g. I 
implemented a preprocessor to pass url parameters as PRP to Portlets under 
certain circumstances. So restricting this point would break existing 
implementations.

In addition, Scott,:
"String[] values = { "Fred", "Wilma", "Pebbles" };
actionResponse.getRenderParameterMap().put("privateRenderParameter3", values);
My take would be that by itself no, it should not. The correct code should be:

String[] values = { "Fred", "Wilma", "Pebbles" };
Map<String, String[]> parmMap = actionResponse.getRenderParameterMap();
parmMap.put("privateRenderParameter3", values);
actionResponse.setRenderParameters(parmMap);"

With that, you would enforce immutable maps. Although I would favor the 
second approach as well, making the first one impossible would break existing 
code. Since the first approach cannot be deprecated (as you would have to 
deprecate a method from java.util.Map), sth like this could be done:

public class DeprecatedMutableMap<String, String[]> extends HashMap<String, 
String[]> {
@Override
public boolean put(String name, String[] values){
logger.warn("calling the put method on this map instance is deprecated. 
Better use ...");
return super.put(name, values);
}
}

Just a rough idea. But that would be highly vendor specific, so it actually 
would not have to be related to the JSR. The JSR would only have to specify, 
that setting the render parameter directly should not be possible (and if it 
is already, it should at least be deprecated).


> Errata: Clarify inconsistencies regarding getting and setting parameters
> ------------------------------------------------------------------------
>
>                 Key: PORTLETSPEC3-8
>                 URL: https://java.net/jira/browse/PORTLETSPEC3-8
>             Project: portletspec3
>          Issue Type: Improvement
>          Components: JSR 286 Portlet Specification Errata
>            Reporter: msnicklous
>            Assignee: msnicklous
>            Priority: Minor
>
> Reading the spec document on parameters and comparing it with the javadoc on
> "get...Parameter..." and "set...Parameter..." calls on various Response, 
> Request, and
> URL classes, it seems to me that there are a number of inconsistencies that 
> should
> be addressed, for example:
> # Is a parameter allowed to have a value of null?
> # Under which cases (if any) should setting a parameter to a value of null 
> remove the parameter?
> # In which cases exactly are public parameters get and set?
> # In which cases are public render parameters set or updated?
> # In which cases are public render parameters removed?
> # Should the "getParameterMap" methods always return an immutable map?
> # probably more that I haven't noticed yet ... 
> To #6 - 
> {noformat}
> The javadoc for PortletRequest.getParameterMap states:
> -------------------------
>     Returns:
>         an immutable Map containing parameter names as keys and parameter 
> values as map 
>         values, or an empty Map if no parameters exist. 
>         The keys in the parameter map are of type String. 
>         The values in the parameter map are of type String array (String[]).
> -------------------------
> While the javadoc for BaseURL.getParameterMap states:
> -------------------------
> Returns:
>     Map containing parameter names as keys and parameter values as map 
>     values, or an empty Map if no parameters exist. 
>     The keys in the parameter map are of type String. 
>     The values in the parameter map are of type String array (String[]).
> -------------------------
> {noformat}
> Shouldn't the returned Map values be consistently immutable? 
> If not, and if we want to be able to update the actual parameters by 
> updating the
> Map returned by BaseURL.getParameterMap, it needs to be described clearly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://java.net/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[JIRA] Commented: (PORTLETSPEC3-8) Errata: Clarify inconsistencies regarding getting and setting parameters

msnicklous (JIRA) 07/26/2013

<Possible follow-up(s)>

[JIRA] Commented: (PORTLETSPEC3-8) Errata: Clarify inconsistencies regarding getting and setting parameters

Neil Griffin (JIRA) 07/30/2013

[JIRA] Commented: (PORTLETSPEC3-8) Errata: Clarify inconsistencies regarding getting and setting parameters

msnicklous (JIRA) 07/31/2013

[JIRA] Commented: (PORTLETSPEC3-8) Errata: Clarify inconsistencies regarding getting and setting parameters

msnicklous (JIRA) 07/31/2013

[JIRA] Commented: (PORTLETSPEC3-8) Errata: Clarify inconsistencies regarding getting and setting parameters

andre.hagemeier (JIRA) 07/31/2013
 
 
Close
loading
Please Confirm
Close