I merged the contributions from Mike and Scott into the master branch. If y'all rebase your forks from upstream you should see the changes now.
Also, I added some instructions to the main README.md file for contributing with GitHub pull requests:
On May 28, 2013, at 8:14 AM, Martin Scott Nicklous <
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
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:
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
Schoenaicher Str. 220
----- Forwarded by Martin Scott Nicklous/Germany/IBM on 28.05.13 13:25
From: Michael Freedman <
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
B) In the ActionPhase after clicking on the ActionURL
publicRenderParameter1: actionURL, renderURL
During the RenderPhase of the action
C) Same as A above -- Resets the render parameter state
D) Phase: RESOURCE_PHASE
publicRenderParameter1: 1, renderURL
What the Spec says
Based on the following pertinent sections in the spec this is exactly what
(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.
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 18.104.22.168 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 22.214.171.124 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
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
Following the action phase, the action response sets the new render
parameter state for the portlet. In this case, the response sets two
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
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