Methods for resetting IBM WebSphere Portal portlet views

Methods for resetting IBM WebSphere Portal portlet 

views 

James Barnes (jwbarnes@us.ibm.com), IBM 

Ryan Wilson (rywilson@us.ibm.com), IBM 

May 2012 

© Copyright International Business Machines Corporation 2012. All rights reserved. 

Abstract: This article explains how to reset portlet views with multiple frameworks (Java 

Specification Request, IBM Web Content Manager, and JavaServer Faces), along with 

examining how the theme impacts the process and can be used to reset the state. Also, we 

examine how the various themes (Portal standard, Portalweb2, PB2) can be modified to 

achieve the desired results. 

Table of Contents 

1 Introduction.............................................................................................................................1 

1.1 WebSphere Portal settings and configurations................................................................2 

2 Modifying themes....................................................................................................................2 

2.1 Portal theme.....................................................................................................................3 

2.2 PortalWeb2 theme............................................................................................................6 

2.3 PageBuilder2 theme.......................................................................................................10 

3 Framework modifications......................................................................................................13 

3.1 JavaServer Faces (JSF)..................................................................................................13 

3.2 Struts Portlet Frame (SPF).............................................................................................13 

3.3 WCM.............................................................................................................................16 

4 Sample portlet........................................................................................................................16 

5 Conclusion.............................................................................................................................17 

6 Resources...............................................................................................................................17 

7 About the authors...................................................................................................................17 

1 Introduction 

A common requirement for portlet developers or portal administrators is to have a portlet 

reset to its default view. This is often desired when navigating to another portal page and 

then returning to the page the portlet is on. The default behavior of IBM® WebSphere® 

Portal is to maintain the previous state of the portlet; however, to understand why, we should 

first look at the different ways a portlet determines its current page. 

1

A portlet can either use renderParameters or a session object to determine the portlet's 

pagination. Though some frameworks [Struts, JavaServer TM Pages (JSP), etc.] hide this, the 

underlying implementation uses one of the two. 

WebSphere Portal maintains a history of the renderParameters associated with the portlet for 

X number of page visits. Since a portlet is a J2EE application, its session is not able to be 

altered by WebSphere Portal and is maintained until a user logout. WebSphere Portal cannot 

implictly clear the session attributes set in a portlet. 

There is nothing in the portlet lifecycle that can be used to identify when the portlet is being 

rendered when returning from another portal page. This means that you must make 

modications to either the configuration, theme, or the portlets to accomplish the desired 

behavior. 

NOTE: The solutions described in this document rely on the functionality of 

renderParameters used during the render phase of the portlet. If you have portlet caching 

enabled for your portlet, then the solutions herein may not work. 

When caching is enabled on the portlet, the cached markup (that was generated during 

the last render) is returned when the portlet is rendered, and the code of the portlet is not 

executed. This means that the clearing of the render parameters will not effect the display 

of the portlet. To change this behavior, you would need to explicitly target an action of 

your portlet. 

1.1 WebSphere Portal settings and configurations 

As noted above, WebSphere Portal maintains a certain history level of the renderParameters 

associated with the portlet. The expiration limit is determined by use of the value of the 

property keymanager.lru.size in the StateManagerService. This value should not be set to 

zero, and negative numbers are not valid. 

Refer to the WebSphere Portal Information Center topic, "Portal configuration services," for 

more information on changing the keymanager. 

2 Modifying themes 

One approach to get the desired behavior is to make modifications to your theme. 

Throughout the last several releases of WebSphere Portal there have been several styles of 

theme. In this paper we cover some of the more popular themes and provide examples of how 

to clear the state. Note that all these approaches affect only the renderParameters on the 

portlet and not session attributes. 

If your portlet uses session attributes to determine the pagination, then you may need to 

combine some of the approaches below with custom code in your portlet. 

For example, rather than clearing the renderParameters in the theme, you could set a specific 

parameter and then check for this parameter in your portlet; if it exists, you could then clear 

your session attribute and display the default page of the portlet. 

2

2.1 Portal theme 

In the most basic theme, it is easy to erase the rich text that is included with page navigation 

within portal. When you remove the rich text, you also remove the state as stored for render 

parameters. This provides a way to reset portlets that rely on render parameters, but you 

cannot affect portlets that rely on the session for their state information. 

Using the base WebSphere Portal/IBM theme 

All pages in which you do not want a rich URL must have a friendly URL. In the example 

shown in figure 1, the page feeds have been modified to have the friendly URL "feeds", and 

the Home page also contains the friendly URL of Home.. 

Figure 1. Example friendly URL creation 

You can create your own theme by following the steps detailed in the WebSphere Portal 

Information Center topic, "Creating a new theme." After creating the theme you would need 

to make the following changes: 

1. Edit the topnav.jspf file and find all occurrences of "navigationUrl". 

2. Add the following to the tag: 

keepNavigationalState="false" 

The final results should look like this: 

 

which will produce a URL that looks like the following in the address bar: 

http://test.ibm.com:10040/wps/myportal/Home/feeds 

3. Repeat these steps in the sidenav.jsp file, if you want to get the same behavior. 

NOTE: Only alter the "navigationUrl" tag that has the type of launch. 

Using the Helpers 

Another way to cause the WebSphere Portal navigation to drop the state is to code this into 

the URL generation. By taking advantage of the URL generation SPIs we can make URLs 

that have no state information in them except for changing a page or targetting a portlet. 

3

You can find the Helpers in the IBM Support Technote, "Portal 6.1 and 7.0 Advanced URL 

Generation Helper classes," as well as more details on how to use them. 

To accomplish this task, we take advantage of the URL generation SPI to build URLs to 

pages with absolutely no state information: 

1. Use the Helper classes to create the URL, using the method in listing 1. 

Listing 1. Code for generateUrlDropState method 

public static String generateUrlDropState( 

NavigationNode wpsNavNode, 

HttpServletRequest request, 

HttpServletResponse response) 

throws StateException, NamingException, IOException { 

final PortalStateManagerService mgr = getStateManager(request, 

response); 

// Get the URL factory 

final URLAccessorFactory urlFactory = (URLAccessorFactory) 

mgr.getAccessorFactory(URLAccessorFactory.class); 

final EngineURL url = urlFactory.newURL(request, response, 

mgr.newState(), Constants.EMPTY_COPY); 

// Set the page this URL should point to 

final SelectionAccessorFactory selectionFactory = 

(SelectionAccessorFactory) 

mgr.getAccessorFactory(SelectionAccessorFactory.class); 

// Request the selection controller to set the page; pass in the 

state associated with the created URL 

final SelectionAccessorController selectionCtrl = 

selectionFactory.getSelectionAccessorController(url.getState()); 

// Set the page; you need the unique name (String) or the 

ObjectID of that page 

selectionCtrl.setSelection(wpsNavNode.getObjectID()); 

// Dispose the accessor (avoids memory leak) 

selectionCtrl.dispose(); 

} 

return url.writeDispose(new StringWriter()).toString(); 

This method returns a string that is the URL to change the page selection. 

2. Next, modify the theme to properly call this method, first adding the import to the 

topnav.jspf file: 

 

3. In the topnav.jspf file, change two lines: 

a) The first line is for the current page URL (if you want the state kept on this page, 

then leave it as is). Change the following: 

4

 

 

to the code in listing 2. 

Listing 2. New code for first line 

 

 

 

 

b) The second line to change is for unselected pages. Change the following: 

 

 

 


Listing 3. New code for second line 

 

 

 

 

4. In the sideNav.jspf file, change the following one line from: 

 

 

 


Listing 4. New code for sideNav.jspf file 

 

(isNodeSelected) { %>onfocus="showPageAffordance()" > 

 

 

The basics of this method are similar to using keepNavigationalState="false" when creating 

URLs using the URLGeneration tag. This is an easier way for your themes in that you don't 

have to hardcode any values. 

In the Download section on the landing page for this paper is a .zip attachment containing a 

sample theme and .jar file with Helper classes. Place the .jar file into the shared/app directory 

of the WebSphere Portal Server directory and deploy the theme, following the standard 

procedures in the Deploying the theme topic in the WebSphere Portal Information Center. 

2.2 PortalWeb2 theme 

The PortalWeb2 was the first theme to introduce client-side aggregation (CSA). Covering all 

the details of CSA is outside the scope of this document; however, we provide some 

information that is needed to understand the changes in PortalWeb2 theme and the 

PageBuilder theme. 

Though designed for CSA, the PortalWeb2 can also be rendered in a force_SSA mode, which 

causes the theme to be rendered in a server-side aggregation (SSA) mode. The theme 

structure/code used in SSA is virtually the same as the Portal theme described above. 

Its important to note that all the information in this section pertains to the pages/portlet 

rendering in CSA mode. If any of the pages/portlets are forcing SSA mode, you must also 

follow the instructions Section 2.1 above. 

Although the portlet cannot detect when there is a change to the portal navigation, the theme 

can. There are several events that occur within the processing of a CSA page. To implement 

the code to clear the navigation, we register a listener for the startPage event, which is called 

when the page is begining to render and is the best hook to clear the render parameters. 

The stateChanged event listenter may look like a promising place to put this code; however, 

it ends up being executed after the rendering is already started, so the changes to the state are 

not picked up. 

1. Create a file named clearNavigationState.js in the js directory of your theme and add the 

content in listing 5. 

Listing 5. Code to add to clearNavigationState.js 

dojo.declare( "com.ibm.portal.aggregation.ClearNavigationalStat 

e", 

null, 

{ 

constructor: function(){ 

// use the EVENT_BROKER.startPage event. 

this._stateChangedStartHandle = 

com.ibm.portal.EVENT_BROKER.startPage.register( this, 

this.start ); 

}, 

start: function(){ 

6

var state = 

com.ibm.portal.navigation.controller.NAVIGATION_CONTROLLER.getS 

tate(); 

var stateMgr = new 

com.ibm.portal.state.StateManager(ibmPortalConfig.contentHandle 

rURI); 

stateMgr.reset( state.stateDOM ); 

//get all the portlets associated with this state 

var portletListAccessors = 

stateMgr.newPortletListAccessor(); 

var portletList = portletListAccessors.getPortlets(); 

if ( portletList ) { 

for(var i = 0; i < portletList.length; i++ ){ 

//get the portlets and clear the renderParameters 

var pAcc = 

stateMgr.newPortletAccessor(portletList[i]); 

pAcc.setPortletMode( ibm.portal.portlet.PortletMode.VIEW ); 

pAcc.setWindowState( ibm.portal.portlet.WindowState.NORMAL ); 

pAcc.getRenderParameters().clear(); 

} 

} 

} 

}); 

com.ibm.portal.aggregation.TEST_NAVIGATION = new 

com.ibm.portal.aggregation.ClearNavigationalState(); 

2. Open the head_extras.jspf file and look for the following line: 

 

We include our script directly after this line by using the following code: 

 

3. Since the head_extras.jspf is included in the head.jspf by use of an include directive, you 

must touch both head.jspf and Default.jsp to force a recompile and have our changes 

picked up. If JSP reloading is not enabled, we will need to restart the server. 

Now that the code is in place we can explain what it does. The first step is registering a 

listener for the startPage event: 

this._stateChangedStartHandle = 

com.ibm.portal.EVENT_BROKER.startPage.register( this, this.start ); 

Now let's look at the start function, as this handles the task of clearing the portlets state. We 

first need to get the StateManager from the state: 

var state = 

com.ibm.portal.navigation.controller.NAVIGATION_CONTROLLER.getState(); 

7


com.ibm.portal.state.StateManager(ibmPortalConfig.contentHandlerURI); 

Then we reset the stateMgr before obtaining the portlet list on the page: 


Next, we get a list of all the portlets on the page and begin iterating through them: 

var portletListAccessors = stateMgr.newPortletListAccessor(); 


The portletList variable is an array of String elements represending the OID of the portlet 

window. For example: 

["7_IP4IHB429GJSB0IL5O9DTN30G5", "7_CGAH47L008JD302B5MRL683G22"] 

To do anything useful we need to get the PortletAccessor, using the OID(Object ID) from the 

list. We do this by using the stateMgr object: 

var pAcc = stateMgr.newPortletAccessor(portletList[i]); 

With the portletAccessor we can now perform the task of clearing the parameters and 

resetting the state. The following code also resets the portlet to view mode, sets the window 

state to normal and, finally, clears all the renderParameters: 




As mentioned above this code only affects the pagination if the portlet was developed using 

renderParameters. If the portlet does use a session object, the above code will not work; 

however, there is a potential solution. 

We not only have the ability to remove renderParameters but also are able to add new ones. 

For example, after clearing all the parameters, you could then add a parameter like the 

following: 

pAcc.getRenderParameters().setValue("clearSession", "true"); 

Now you can develop your portlets to listen for this parameter and then manually remove the 

pagination object from the session. 

Another thing to note is that the above code will clear the parameters for all portlets and 

pages. If you want only certain portlets/page to be cleared, you could create a list of the 

pages or portlets that should or should not be cleared. For example: 

In the constructor of the ClearNavigationState class above, add the following: 

this._pageList = ["ClearNavigationalState_1"]; //list of page 

titles to clear. 

8

In this example the list uses the page title, but we could also use the OID of the page. The 

above code assumes that you have a page titled "ClearNavigationalState_1" in your 

environment and you want all the portlets on this page to be reset. 

After the start function (referenced in Step 1) you need to add a new function (see listing 6): 

Listing 6. Add a new function 

clearPage: function(id){ 

for(i = 0; i < this._pageList.length; i++){ 

if(id === this._pageList[i]){ 

return true; 

} 

} 

} 

return false; 

Finally, change the start function to look like that shown in listing 7. 

NOTE: The start function is the first function in the 

com.ibm.portal.aggregation.ClearNavigationalState class. Functions must be separated by 

comma's for the Dojo declared object, so be sure to add a comma after the closing bracket of 

the start function when adding the new clearPage function. 

Listing 7. Code to change the start function 

start: function(){ 

var state = 

com.ibm.portal.navigation.controller.NAVIGATION_CONTROLLER.getState( 

); 

var selectedNode = 

state.selectionModel.getSelectedNode(); 

console.log(selectedNode.title); 

if(this.clearPage(selectedNode.title)){ 


com.ibm.portal.state.StateManager(ibmPortalConfig.contentHandlerURI) 

; 


//get all the portlets associated with this state 

var portletListAccessors = 

stateMgr.newPortletListAccessor(); 


if ( portletList ) { 

for(var i = 0; i < portletList.length; i++ ){ 

//get the portlets and clear the renderParameters 

var pAcc = 

stateMgr.newPortletAccessor(portletList[i]); 



9


pAcc.getRenderParameters().setValue("clearSession", "true"); 

}, 

} 

} 

} 

Now the portlets will be cleared only for pages that are in the list. 

2.3 PageBuilder2 theme 

As with the PortalWeb2 theme, the PageBuilder2 theme supports a CSA and SSA mode of 

rendering. However instead of having a fallback behavior, the PageBuilder2 theme uses a 

similar code path for the navigation to support both modes. This means that the same code 

can be used for both rendering modes. 

With this model, portlets are wrapped in an iWidget. We will reference iWidgets throughout 

the remainder of this paper and sample codes; however, for the context of this section the 

term iWidget also represents the underlying portlet. 

The PageBuilder2 theme uses a subscribe/publish event model. This provides a mechanism 

for components to be notified of events such as a navigational change to another portal page. 

The NavigationController is the core object used for handling the navigational changes for 

the theme. 

The switchPageHandler function is a member of the NavigationController and is registered to 

listen for the SWITCH_PAGE event. In the provided sample code we extend this function to 

clear the state. We list the code snippet and then explain what the code is doing. 

For simplicity you can place the code in listing 8 into the theme_.html file of your 

theme, after the config DCS (Dynamic Content Spot): 

. 

Listing 8. Code to put in theme_.html 

 

(function(){ 

var c = com.ibm.pb.control.NavigationController.getController(); 

var origSwitchPageHandler = c.switchPageHandler; 

c.switchPageHandler = function(pageNode, status, semantics) { 

var navStateModel = 

com.ibm.mashups.enabler.model.state.NavigationStateModelFactory.getN 

avigationStateModel(); 

// clear all the parameters for all the widgets and such 

// then commit the navigation state model 

// then call... 

//get the navigationModel 

10

var nModel = 

com.ibm.mashups.enabler.model.Factory.getNavigationModel(); 

//var locator = nModel.getLocator(); 

//var navNode = locator.find(pageNode.getID()); 

var defferedNavNode = nModel.find(pageNode.getID()); 

var navNode = defferedNavNode.start(); 

var layoutModel = nModel.getLayoutModel(navNode); 

if(layoutModel){ 

var iWidgetList = getiWidgets(layoutModel); 

} 

//clear WCM shareable render parameters 

//Look for the public-render-parameter scope parameter on 

the page. 

var scopeParam = navNode.getMetaData("param.sharing.scope"); 

if(scopeParam){ 

var publicRenderParameters = 

com.ibm.mashups.enabler.model.state.AccessorFactory.getShareablePara 

meterSetAccessor(navStateModel, "public-render-parameters", 

scopeParam); 

} else { 

//Public render parameters are not scoped to the page 

so get the global scope. 

var publicRenderParameters = 

com.ibm.mashups.enabler.model.state.AccessorFactory.getShareablePara 

meterSetAccessor(navStateModel, "public-render-parameters"); 

} 

//publicRenderParamsNames = 

publicRenderParameters.getAllNames(); 

//WCM specific public render parameters. 

var removePath = 

publicRenderParameters.removeItem("{http://www.ibm.com/xmlns/prod/we 

bsphere/portal/publicparams}path-info"); 

var removeContext = 

publicRenderParameters.removeItem("{http://www.ibm.com/xmlns/prod/da 

tatype/content}context"); 

var removePageDesign = 

publicRenderParameters.removeItem("{http://www.ibm.com/xmlns/prod/da 

tatype/content}page-design"); 

if(iWidgetList){ 

for(var i = 0; i < iWidgetList.length; i++){ 

var widgetAccessor = 

com.ibm.mashups.enabler.model.state.AccessorFactory.getWidgetAccesso 

r(navStateModel, iWidgetList[i]); 

var stateNames = widgetAccessor.getWidgetStateNames(); 

if(stateNames){ 

for(var x = 0; x < stateNames.length; x++){ 

//add error checking for null 

widgetAccessor.removeWidgetState(stateNames[x]); 

} 

} 

} 

11

}; 

} 

var deferred = navStateModel.commit(); 

//deferred.setFinishedCallback(cb); 

deferred.start(); 

return origSwitchPageHandler.apply(this, arguments); 

var getiWidgets = function(layoutModel){ 

var iWidgetsList = new Array(); 

var iterateLayoutModel = function(node){ 

//check to see if the node is of type 

if(node.getLayoutNodeType() == 

com.ibm.mashups.enabler.layout.Constants.LAYOUT_CONTROL){ 

//add the node ID to the array since this represents 

a widget on the page 

iWidgetsList.push(node.getID()); 

} else { 

var children = layoutModel.getChildren(node); 

while(children.hasNext()){ 

iterateLayoutModel(children.next()); 

} 

} 

}; 

iterateLayoutModel(layoutModel.getRoot().start()); 

return iWidgetsList; 

} 

})(); 

 

Since we need to call the original switchPageHandler function after our processing, we need 

to first save the original function to be called later. Once we have the original function saved, 

we can overwrite the switchPageHandler function in the NavigationController and, using the 

enabler APIs, we obtain the layout of the target page. 

The layout is needed to obtain a list of the portlets on the page. The sample code provides a 

function named getiWidgets that iterates the layoutModel, looking for nodes that are of type 

com.ibm.mashups.enabler.layout.Constants.LAYOUT_CONTROL. These nodes represent 

the portlets on the page. 

We can then iterate through the list of iWidget IDs and use the WidgetAccessor APIs to get 

the state names, which represent the renderParameters associated with the portlet. We can 

also add a renderParameter for use in the portlet code. For example, we can add the 

clearSession parameter that the portlet can detect and then clear an attribute from its session: 

widgetAccessor.setWidgetState("clearSession", ["false"]); 

We could also look for and remove public-render-parameters. The sample code contains a 

snippet for removing three public-render-parameters that are commonly used in IBM Web 

Content Manager (WCM) rendering portlets. 

12

3 Framework modifications 

3.1 JavaServer Faces (JSF) 

The easiest way to reset the state is by using one of the above methods that clears the render 

methods (most often, setting the keymanager) and setting the JSF framework to save its state 

as render paramaters. 

Refer to IBM Support Technote #1424426, "JSF Portlet Development Migration topics: Tips 

and Suggestions" (the section under Performance tuning tips), for more information about 

using the session vs. the render parameters. Be aware that using render parameters can lead to 

long URLs that some browsers cannot handle. 

The JSF portlet bridge, as provided by IBM previously, stored its state in the session. If you 

are storing the state in the session, the state of the portlet is maintained by the 

portlet/framework itself and would need to be cleared by direct action. 

The best way to do this is to target an action in the portlet that resets the state. This link 

would be from other pages that target this page, so that when the page is changed, the portlet 

action is also fired, causing the action to reset. 

You could do this as well in your portlet by setting the following: 

portletSession.setAttribute("com.ibm.faces.portlet.page.view", 

); 

3.2 Struts Portlet Frame (SPF) 

The SPF uses a session attribute to determine the pagination. The typical flow of an SPF 

portlet is to render a landing page and then, when an action is executed, an IViewCommand 

object is created and stored into the session. 

This IViewCommand object contains the information needed to render the page. When the 

portlet is rendered again, the SPF will determine whether an IVewCommand object is already 

present in the session; if so, this is used to render the last view of the portlet. 

The Struts Portlet Framework does provide a flag interface named IstrutsSingleAction that 

allows the action to be executed once, and the resulting IviewCommand is created and stored 

into the session. 

The portlet is then rendered by use of the results of the created IviewCommand. However, 

when the portlet is rendered again, the IviewCommand is removed from the session, and the 

portlet is rendered with its default page. 

It is important to understand that this behavior is tied to the rendering of the portlet and not a 

portal navigation change. This means that the portlet will be "reset," if another portlet on the 

page causes the page to be updated, or the page is simply refreshed. 

The following example deomonstrates the IstrutsSingleAction: 

We first create a landing page with two links, one of which is to a "regular" Action, and the 

other is to an IstrutsSingleAction (see listing 9) 

13

Listing 9. Code for landing page 

 

 

You're on the landing page. 

Click to execute the 

IStrutsSingleAction 

Click to execute the 

Action 

The action mappings are set to the code shown in listing 10. 

Listing 10. Action mapping code 

 

 

 

 

 

 

 

Let's first look at the ExecuteAction class and the regularAction.jsp. As you can see from 

listing 11, the ExecuteAction is a very simple class that returns the mapping to the jsp. 

Listing 11. ExecuteAction class 

public class ExecuteAction extends StrutsAction { 

public ActionForward execute(ActionMapping mapping, ActionForm 

form, 

PortletRequest request, PortletResponse response) 

throws Exception { 

} 

} 

ActionForward forward = mapping.findForward("success"); 

return forward; 

Then the regularAction.jsp prints a simple message, as shown in listing 12. 

Listing 12. regularAction.jsp 

 

14

 

 

This is the result of a regular StrutsAction. 

Next, place this portlet on a page and select the "click to execute Action" link. The content in 

listing 12 will be displayed in the portlet. If you navigate to another WebSphere Portal page 

and back, you will notice that the same content is displayed. 

Now let's examine the IstrutsSingleAction by first looking at the ExecuteSingleAction class 

(see listing 13). 

Listing 13. ExecuteSingleAction class 

public class ExecuteSingleAction extends StrutsAction implements 

IStrutsSingleAction { 

public ActionForward execute(ActionMapping mapping, ActionForm 

form, 

PortletRequest request, PortletResponse response) 

throws Exception { 

} 

} 

ActionForward forward = mapping.findForward("success"); 

return forward; 

As you can see, this action is quite similar to the previous one, except that this one 

implements the IstrutsSingleAction interface. As mentioned before, this is a flag interface, so 

there are no methods to implement. Like the regularAction.jsp, the IstrutsSingleAction.jsp 

displays a simple message (see figure 14). 

Listing 14. IstrutsSingleAction.jsp 

 

 

 

 

This is the result of an IStrutsSingleAction. 

This page should not be displayed when refreshing this portal page 

or when returning to this portal page from a different portal 

page. 

Log out of WebSphere Portal and then log back in. This clears the state since we have set the 

state in the session with the standard action. Navigate to the page where this portlet is 

deployed, and this time select the "Click to execute the IstrutsSingleAction" link. You will see 

the content from listing 14 displayed on the page. 

15

If you navigate to another WebSphere Portal page and back, this time you should see the 

landing page instead the above content. 

The IstrutsSingleAction interface provides the powerful ability to reset the portlet view while 

requiring minimal code changes. Specifically, it only requires adding the interface and does 

not require any other portlet or theme code changes. 

3.3 WCM 

When using previous versions of WCM you may want the rendering portlet to reset when you 

return. By default the older versions of the rendering portlet save these items to the session. 

In newer versions it will use render paramaters, so if you used one of the procedures in 

Sections 2.1, 2.2, or 2.3 above to target resetting render paramaters, it will clear its state. 

With the older version of the portlet you must modify your navigation to also pass a URL 

parameter that can be read by the portlet to reset its state. 

First you must configure the portlet to "receive links from other portlets and this portlet". You 

can find this in the links configuration for the portlet, under Edit shared settings. Then in your 

theme navigation loops, you have your links created by the code in listing 15, assuming you 

are using the default page navigation that uses navigationLoop tags. 

Listing 15. Code to create links 

 

 

 

 

 

 

 

 

4 Sample portlet 

Included with the Download file is a sample portlet that uses the session object to control the 

current view. The portlet was coded such that, when you use the pagination links, the .jsp 

name is set into the session: 

session.setAttribute(SESSION_OBJECT, jsp) 

On each page view it is checked to determine whether a page change has been selected; if 

not, the current page is pulled from the session and used as the view: 

String state = (String)session.getAttribute(SESSION_OBJECT); 

jsp = state; 

16

To be able to reset the session, we have enabled the portlet to look for a request parameter 

and, if present, to remove the session object and reset the view back to the base view (see 

listing 16. 

Listing 16. Code to reset session 

String resetState = request.getParameter("clearSession"); 

System.out.println("The resetState ={" + resetState + 

"}"); 

PortletSession session = request.getPortletSession(); 

if((resetState !=null) && (!resetState.equals(""))) { 

session.removeAttribute(SESSION_OBJECT); 

System.out.println("Resetting state now"); 

jsp = VIEW_JSP; 

This works with the other download samples we have provided and is a good way of testing 

your basic theme changes that effect portlets that rely on the state in the session. 

5 Conclusion 

We have presented several methods for resetting the state of your page that, taken together, 

can be used to customize your site and deliver the desired experience for your users. You can 

use this to reset portlets on all pages or on only some page. Just be sure to use strategies like 

these only where they makes sense; otherwise, you may be dealing with upset users 

complaining that the design is not behaving as expected. 

You should also now have a good understanding of how the various frameworks manage their 

state. Many portlets probably manage the state in the session and, as a J2EE application, other 

portlets and the Portal application cannot modify those sessions. 

It is up to each application to modify their own session and state. Additionally, other factors 

like caching may impact how the portlet renders, so make sure to test your solution on a 

production look-alike, to ensure it behaves as expected. 

6 Resources 

Participate in the discussion forum. 

WebSphere Portal product documentation. 

developerWorks® WebSphere Portal zone. 

WebSphere Portal Family wiki. 

7 About the authors 

James Barnes is a Level 2 Engineer for the WebSphere Commerce team and is based at IBM's 

RTP, North Carolina, facility. He joined IBM in 1999 and then moved to Level 2 Support in 

2003, focusing on development-related issues. He holds Certifications for WebSphere Portal 

development (5.1, 6.0, 6.1, 7.0) and WebSphere Portal Administrator (5.0, 5.1, 6.0), and 

earned a B.Sc. in Agriculture and Applied Economics from Virginia Tech University. 

17

Ryan Wilson is the Technical Lead for the WebSphere Portal Level 2 API/Migration team in 

RTP, North Carolina. His areas of expertise include Java Platform, Enterprise Edtion, 

application development with IBM WebSphere Studio and IBM Rational® Application 

Developer. Ryan holds certificates in WebSphere Portal development (versions 5.1, 6.0, 7.0), 

and is a Java Certified Programmer and Java Certified Web Component Developer. 

Trademarks 

• developerWorks, IBM, Rational, and WebSphere are trademarks or registered trademarks 

of IBM Corporation in the United States, other countries, or both. 

• Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the 

United States, other countries, or both. 

• Other company, product, or service names may be trademarks or service marks of others. 

18

Methods for resetting IBM WebSphere Portal portlet views

Create successful ePaper yourself

Delete template?

Save as template?