Skip to main content

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

  • From: Martin Scott Nicklous < >
  • To:
  • Subject: [jsr362-observers:] [jsr362-experts:] Fw: Public Render parameters
  • Date: Tue, 28 May 2013 14:14:29 +0200
  • List-id: <jsr362-experts.portletspec3.java.net>



Mike,

thanks for your detailed and most excellent summary of how the public
render parameters are supposed to work. I actually came to the same
conclusion on my own, which is reassuring.

Last week we noted that the thing to do was to actually try out the code
and fit the results to what is written in the specification and API
documentation, so I did so ... at least, I tried out as many points as I
could.

I continued up my learning curve in several areas - Git, Subversion, Maven,
Eclipse, wikitext & portlets. I wanted to look into these things anyway,
but last week I was forced to sort of. It was a good thing. I got far
enough along that I was able to check out and build Neil's portlets, and I
got a Pluto portal running, so I can test both on Pluto and WebSphere.
There is still room for improvement, since my Maven build didn't work as I
think it should have, and I have a number of other sort of tooling
problems,  but I set up the build in sort of a brute-force manner and got
the job done.

Anyway, as Mike did, I also expanded on the portletbox portlets, see
attached archives. I added a routine to HTMLUtil to write the output in a
more compact manner, so that I could summarize the output more easily in
tables. I also extended the PORTLETSPEC3-8 and PORTLETSPEC3-10 portlets to
add additional data display, links, and tests.

I summarized the results in the Wiki (see:
https://java.net/projects/portletspec3/pages/JSRParameterTests ;), and
finished with that more or less just now, so I haven't yet gone through the
results methodically in order to map them to JIRA items or the spec. I hope
to make some progress in that area in the next few hours before our call
today.  The results in the table are all for Pluto. As we go through the
issues, I will add new tests & results as necessary.

(See attached file: PORTLETSPEC3-8.war)(See attached file:
PORTLETSPEC3-10.war)

Mit freundlichen Grüßen / Kind regards

Martin Scott (Scott) Nicklous

WebSphere Portal Standardization Lead & Technology Consultant
Specification Lead, JSR 362 Portlet Specification 3.0
IBM Software Group, IBM Collaboration Solutions
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
 Phone:            +49-7031-16-4808           IBM Deutschland Research &      
     (Embedded
                                             Development GmbH                 
   image moved
                                                                              
      to file:
                                                                              
 pic23886.gif)
                                                                       
 E-Mail:           

  Schoenaicher Str. 220    
                                                                       
                                              71032 Boeblingen         
                                                                       
                                              Germany                  
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
 IBM Deutschland                                                       
 Research &                                                            
 Development                                                           
 GmbH /                                                                
 Vorsitzender des                                                      
 Aufsichtsrats:                                                        
 Martina Koederitz                                                     
                                                                       
 Geschäftsführung:                                                 
 Dirk Wittkopp                                                         
 Sitz der                                                              
 Gesellschaft:                                                         
 Böblingen /                                                         
 Registergericht:                                                      
 Amtsgericht                                                           
 Stuttgart, HRB                                                        
 243294                                                                
                                                                       


----- Forwarded by Martin Scott Nicklous/Germany/IBM on 28.05.13 13:25
-----

From:   Michael Freedman 
< >
To:     
,
Date:   24.05.13 23:25
Subject:        [jsr362-experts:] Public Render parameters



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" deleted by Martin Scott
Nicklous/Germany/IBM]

Attachment: PORTLETSPEC3-8.war
Description: Binary data

Attachment: PORTLETSPEC3-10.war
Description: Binary data

Attachment: pic23886.gif
Description: GIF image



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

Martin Scott Nicklous 05/28/2013

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

Neil Griffin 05/28/2013

<Possible follow-up(s)>

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

Martin Scott Nicklous 05/28/2013
 
 
Close
loading
Please Confirm
Close