Adam Kewley walks us through how to implement your own portlet page tracker which will not only be able to tell when page changed, but also track whether or not a portlet has registered this page change.
by Adam Kewley
Once in a while during product development we run into scenarios where we need to extend the functionality of IBM Web Experience Factory (WEF) & IBM WebSphere Portal above and beyond what’s supported out of the box. The product goes a long way to make things easier to develop with but it’s impossible (and impractical) to expect it to cover every scenario. Fortunately we can usually rely on custom API and sample workarounds to get us through. This article will discuss one such scenario: Tracking Portal Page states with WEF.
In general a portlet isn’t supposed to know (or care) which page it is placed on. It also shouldn’t worry which page the user was on previously. Due to this construct, it’s not always easy to tell when a portlet is being reloaded or when it’s processing a request from a form action.
In some instances however, a project may require a portlet to refresh itself when a user navigates back to that page. A client may wish that an input form resets itself despite what the JSR specification may state. IBM provides a few API classes that expose the page structure. We’ve used them in the past to get the unique page name as well as generate a portal navigation menu inside of a portlet. In this segment we will discuss how to implement your own portlet page tracker which will not only be able to tell when page changed, but also track whether or not a portlet has registered this page change.
The WebSphere Portal API provides the ModelUtil and NavigationNode classes to gain access to the page models within the portal. Using the following sample code, we can obtain the unique name of the current portal page: