Handling Global Parameters and Events in WLP 9.2

Monday, February 19, 2007

When building a portal, there is often a need to handle certain specific request parameters and inter-portlet events at a global level rather then at a portlet level, this blog post describes one technique for accomplishing this.

Inter-portlet communication (IPC) is a powerful technique for exchanging messages between portlets in a loosely coupled fashion, it allows portlets to work together with no knowledge of where each other is located in the Portal structure. However like most things, except for maybe Chuck Norris, it does have one achille's heel and that is the fact that only portlets can send and receive IPC events.

This issue becomes evident on larger portal projects when you may find quite a few instances where you would like to be able to send or receive an event on a global basis. As an example, when certain parameters are posted to the portal from an external web site you may want to send an event to initiate an action. Or maybe you want to have an event handled at a global level since it affects the portal itself rather then an individual portlet.

A common technique for doing this is to simply place a dummy portlet on a non-visible page. This works well with respect to sending and receiving events, but will not work if you want to send an event in response to posted parameters unless you force the hidden page to be active. Additionally, another weakness with this technique is that with streaming portals it is possible for an administrator to accidentally remove the portlet without understanding what it is doing.

An alternative technique that I prefer is to create a controller portlet that is embedded in the shell. Embedding the portlet in the shell ensures that the portlet will participate in every request and always be present. Additionally, the administrator can only remove the portlet by changing the shell which is not likely to happen and can be avoided by embedding the portlet in all available shells.

Embedding the portlet in the shell is straightforward, simply open the target .shell file and then use the netuix:portletInstance element to embed the portlet within the netuix:header element. Here is an example:

<netuix:header>
    <netuix:portletInstance 
        instanceLabel="_eventController" 
        markupType="Portlet"     
        contentUri="/portlets/controller/controller.portlet"/>
</netuix:header>

Another thing I have been exploring is to combine this technique with Spring to register backing file services for use with the controller portlet. Instead of having one large backing file that handles everything, I have many small service classes that are injected into the backing file of the controller portlet. I’ll post more about this later.

Posted by Gerald Nunn at 4:02 PM | Categories: WebLogic | | | Permalink