Skip to main content

[jsr362-observers:] [jsr362-experts:] Public Render parameters

  • From: Michael Freedman < >
  • To:
  • Subject: [jsr362-observers:] [jsr362-experts:] Public Render parameters
  • Date: Fri, 24 May 2013 14:24:53 -0700
  • List-id: <jsr362-experts.portletspec3.java.net>
  • Organization: Oracle Corporation

I doctored up Neil's 3-5 test portlet to more fully test/express what is going on so we can get a clear explanation of what the specification intended.  We need that before we can discuss/suggest how this confusing area can be better explained and/or fixed.

To Neil's portlet.  I added a link (renderURL) that sets both a public and private render parameter.  The public render parameter I introduce is the same name as the one Neil has declared and places on the actionUREL/resourceURL -- it just has a different value.  Now when I run the test I do the following: 
    a) click the renderURL to set the render parameters
    b) click the action url
    c) click the renderURL to reset the render parameters
    d) click the resource url

I have attached a zip of the code as I also doctored the output/rendering to remove much of the clutter so I could see the results more readily.

Pluto Results (which are correct according to the spec)


A) After clicking on the RenderLink to set the public/private render parameters
  publicParameterMap
    publicRenderParameter1: renderURL

  privateParameterMap
    privateRenderParameter1: renderURL

  parameterMap
    publicRenderParameter1: renderURL
    privateRenderParameter1: renderURL

B) In the ActionPhase after clicking on the ActionURL
    publicParameterMap
        publicRenderParameter1: renderURL

  privateParameterMap
    Pluto_PORTLETSPEC3_5_portlet_1_0_0_SNAPSHOT_1_764587357_0_formParameter1: 1
    actionURLParameter1: 1
    publicRenderParameter1: actionURL

  parameterMap
    Pluto_PORTLETSPEC3_5_portlet_1_0_0_SNAPSHOT_1_764587357_0_formParameter1: 1
    actionURLParameter1: 1
    publicRenderParameter1: actionURL, renderURL

During the RenderPhase of the action
  publicParameterMap
        publicRenderParameter1: actionResponse

  privateParameterMap
    privateRenderParameter1: actionResponse

  parameterMap
    publicRenderParameter1: actionResponse
    privateRenderParameter1: actionResponse


C)  Same as A above -- Resets the render parameter state

D)   Phase: RESOURCE_PHASE
    publicParameterMap
        publicRenderParameter1: renderURL

  privateParameterMap
    Pluto_PORTLETSPEC3_5_portlet_1_0_0_SNAPSHOT_1_764587357_0_formParameter1: 1
    resourceURLParameter1: 1
    privateRenderParameter1: renderURL
    publicRenderParameter1: 1

  parameterMap
    Pluto_PORTLETSPEC3_5_portlet_1_0_0_SNAPSHOT_1_764587357_0_formParameter1: 1
    resourceURLParameter1: 1
    publicRenderParameter1: 1, renderURL
    privateRenderParameter1: renderURL


What the Spec says

Based on the following pertinent sections in the spec this is exactly what one expects:

(I.e. spec says:
PLT 11.1.2: Public Render Parameters page 77 line 32:

In order to allow coordination of render parameters with other portlets, within the same portlet application or across portlet applications, the portlet can declare public render parameters in its deployment descriptor using the public-render-parameter element in the portlet application section. Public render parameters are available in all lifecycle methods of the portlet: processAction, processEvent, render, and serveResource.

Spec refs:
PLT 7.1.1 BaseURL:  paragraph 2 line 14:
Setting parameters on an ActionURL will result in action parameters, not render parameters or public render parameters.

PLT 11.1.2 PRP page 79:
A portlet can access the public render parameters in any lifecycle method via the getPublicParameterMap method of the portlet request. In addition the portlet can access public render parameters via the getParameter and getParameterMap methods. In the case of a processAction or serveResource call the public parameters are merged with the action / resource parameters set on the action / resource URL. If a action or resource parameter has the same name as a public render parameter the public render parameter values must be the last entries in the parameter value array.

PLT 11.1.1.3 Render Request Parameters paragraph 2 line 5
If a portlet receives an event that is the result of a client request targeted to another portlet in the portal page, the parameters should be the same parameters as of the previous render request from this client.

PLT 11.1.1.3 Render Request Parameters: last paragraph line 21

Note that render parameters get automatically cleared if the portlet receives a processAction or processEvent call and need to be explicitly re-set on the response of such a lifecycle call.

PLT 13.6 ResourceURL: line26
Parameters set on a resource URL are not render parameters but parameters for serving this resource and will last only for the current serveResource request.


Explaining the results:

A) Setting parameters on a RenderURL indicates that when clicked these parameters should become the portlet's current render parameters.  If one or more of these parameter names match the portlets declared public render parameters then those parameters will be considered as public render parameters otherwise they are regular (opaque) render parameters.  Hence setting the URL parameter publicRenderParameter1=renderURL and privateRenderParameter1=renderURL results in the two parameters output from getParameter -- one being public and the other private.

B) While in this state if you now click on the "Invoke ActionPhase button" you are invoking an action URL which also had parameters encoded in it (when it was created).  The are two: publicRenderParameter1=actionURL and actionURLParameter1=1.  In addition the form contains a single form parameter that is submitted in the POST body. 

When the action phase is called it reports we have a public render parameter called publicRenderParameter1=renderURL and three private parameters; the two added to the actionURL and the form parameter. The prior private render parameter "privateRenderParameter1" is not present.

The spec statement: "Note that render parameters get automatically cleared if the portlet receives a processAction or processEvent call and need to be explicitly re-set on the response of such a lifecycle call" explains why the existing private render parameter isn't delivered.

The spec statement: "Setting parameters on an ActionURL will result in action parameters, not render parameters or public render parameters."  and "n the case of a processAction or serveResource call the public parameters are merged with the action / resource parameters set on the action / resource URL. If a action or resource parameter has the same name as a public render parameter the public render parameter values must be the last entries in the parameter value array." explains why we get two publicRenderParameter1 values in the request, one considered the public render parameter (containing its value of renderURL) and the other considered an action (private) parameter (containing its value of actionURL).    I.e. an actionURL parameter can't change/alter/add a public render parameter.  All actionURL parameters are action parameters (private).  The consumer however is responsible for send the current set of public render parameters to every portlet request.  Since there is one (publicRenderParameter1=renderURL) it is sent along with the action parameters.

Following the action phase, the action response sets the new render parameter state for the portlet.  In this case, the response sets two render parameters:
publicRenderParameter1: actionResponse and privateRenderParameter1: actionResponse.  So when we hit the render phase these are the two parameters that are seen.

C) Resets state to what we had in A so that (D) runs from the same base.

D) Unlike actions, resource requests don't clear the (private) render parameters.  In fact the spec talks about how they are implicitly added to the ResourceURL to ensure they will exist when invoked.  This is why privateRenderParameter1: renderURL shows up in the (private) parameter map.  Like actions however, all parameters explicitly set on the ResourceURL are serveResource parameters -- not (public) render parameters. This again explains why we receive two references to publicRenderParameter1, one the public on and one the private one.

Bottom line: there are only two ways to set render parameters from within a portlet:
     1) any parameter set on a RenderURL is a render parameter.  Its public if its name matches.
     2) response from an action or event.

Calling an action or event clears existing private render parameters but not the public ones.  Calling a resource implicitly carries the private render parameters (and the public ones).

Confusing as heck, right? 
     -Mike-

Attachment: portletbox-master.zippy
Description: Zip compressed data



[jsr362-observers:] [jsr362-experts:] Public Render parameters

Michael Freedman 05/24/2013
 
 
Close
loading
Please Confirm
Close