ShowTable of Contents
Public render parameters (PRPs) allow JavaTM
Portlet Specification (JSR) 286 portlets to share navigational state information across portlets. In this article we discuss how JSR 286 portlets developed using IBM® Web Experience Factory (WEF) can publish/subscribe/remove the PRPs.
WEF comes with out-of-the-box (OTB) support for working with PRPs by means of its Portlet Adapter builder. The Portlet Adapter builder input for PRPs looks like that shown in figure 1.
Figure 1. PRPs Portlet Adapter builder input
As the figure shows, OrderID is the name of the PRP, and the parameter is shared with the global name OrderID in the namespace http://acme.example.com
Both the publishing and subscribing portlets need to define the render parameter in their respective Portlet Adapter builder inputs. In the attached sample, there are two portlets, PRPPublisher and PRPSubscriber. The PRPPublisher portlet publishes the render parameter named OrderID, and the PRPSubscriber portlet subscribes to this render parameter.
After the changes are made in the Portlet Adapter builder, when the WEF project is published from the workspace, the following entry is created in the Portlet.xml:
And for the portlets that publish or subscribe to PRP, the entry shown in listing 1 is added in Portlet.xml for those portlets.
Listing 1. Entry added to Portlet.xml
In this listing, the PRPSubscriber portlet supports the OrderID PRP, indicating that the portlet is ready to publish/subscribe to the specified render parameter.
Publishing the PRP
JSR 286 portlets can publish the PRP by calling the ActionResponse.setRenderParameter method. Listing 2 shows an example snippet for publishing the PRP. This snippet uses reflection to avoid pulling in IBM WebSphere Portal JARs into the designer/compile classpaths; alternatively, a Linked Java Object (LJO) could be used to call this directly.
Listing 2. Example snippet
The publishing portlet must use the above code snippet for publishing the render parameter. After the render parameter is published, all the subscriber portlets will be able to read the parameter from the request.
Subscribing to the PRP
To read the render parameter from the request, the subscriber portlet needs to handle the OnRequest Event, using the onRequest Event handler in WEF.
The following code is used to read the render parameter from the request by the subscriber portlet:
After the subscriber portlet reads the PRP value, the corresponding value must be cleared from the request because the onRequest Event handler is called on every request, and if it’s not removed, the portlet would react to the PRP on every request, which is not desirable.
Removing the PRP
The OnRequest event handler is called for every action in the portlet, so removal of PRP is handled in the OnRequest event handler itself. ActionResponse has the method removePublicRenderParameter to remove PRP, but there is no such method in RenderResponse.
So, if after the PRP is read, a user action occurs in the subscriber portlet that causes a full page refresh, then the PRP can be removed by use of the following code:
This can be done in the OnRequest event handler itself. However, if after the PRP is read, some action is executed in the subscriber portlet that causes a partial page refresh (RenderResponse), then the above code won’t be executed.
This is because JSR-286 resource requests (used for Ajax / partial page refresh) are not allowed to change the navigational state of the application; that is, render parameters cannot be changed/removed because the RenderResponse class does not have the corresponding methods to modify render parameters.
To overcome this issue, the following approach is used:
The publishing portlet needs to ensure that each PRP value it publishes is unique. In the attached sample, the OrderID value itself is unique, but generally a unique timestamp (or something similar) can be set with the PRP value every time it is published.
When the subscriber portlet receives the PRP value, it reacts to the PRP, storing this unique OrderID value in a variable. Now after reading the PRP value, when any Ajax operation is executed in the subscriber portlet that causes a partial page refresh, then the onRequest handler is called again, and PRP would be received again.
However, this is the render phase of the Portlet, so PRP cannot be removed since RenderResponse doesn’t have the corresponding method. So the subscriber portlet now compares the OrderID in the incoming PRP against the saved OrderID value. If they are the same, then the portlet doesn't need to react to the PRP again, and the PRP need not be removed.
If there is a mismatch in the OrderID, then the portlet updates the stored OrderID with the new value, reads the new render parameter, and reacts to it. This also takes care of the scenario in which the same OrderID is published multiple times from the publishing portlet, so the subscriber need not react to it every time.
This way, the “Ajax-ified” operations would also work as desired in the subscriber portlet, even when the PRP is set in the incoming request.
Running the sample
To run the attached .zip sample:
- Create a WEF project and add the Tutorials and Samples feature set to the project.
- Import the attached .zip as “WebSphere Portlet Factory Archive” into the project.
- Publish the project.
- Create a page in WebSphere Portal and place PRPPublisher and PRPSubscriber on a page.
- Specify an order ID in the search field in the PRPPublisher portlet and click the Search button.
PRP is published on click of the Search button, and the PRPSubscriber portlet should show the details of the order specified in PRPPublisher portlet.
This article has shown you how to work with PRP in WEF 7.0.1 and provided a sample for publishing, subscribing, and removing the PRP in JSR 286 portlets developed using WEF.
developerWorks IBM Web Experience Factory product page:
InfoCenter topic, “Public render parameters”:
About the author
Jyoti Rani is a Software Developer currently working on IBM Connections integration with WebSphere Portal and on developing portlets for IBM Connections services. She can be reached at firstname.lastname@example.org