Newbie to Portlets(Part II)

Request Handling in Portlets

Let us first understand the architecture of portlets. It is very much similar to that of servlets. The portlets are also controlled by the Portlet Container which resides in any Portal Server similar to Servlet Container. The following lines taken from Jsr-168 specifications guide better explains, how the container works. “Users access a portal by using a client device such as an HTML browser or a web-enabled phone. Upon receiving the request, the portal determines the list of portlets that need to be executed to satisfy the request. The portal, through the portlet container, invokes the portlets. The portal creates the portal page with the fragments generated by the portlets and the page is returned to the client where it is presented to the user”. This is can better understood by the following diagrams (from JSR168 specifications).


As portlets are built over servlets it has all the basic features of servlets like Multi-Threaded, Procedure of Loading Class loaders, Request and Response semantics are also similar. The container loads the portlet and then calls its init() method. There are two versions of this method. The first version receives the PortletConfig object and stores it away for later use. This version then calls the parameter-less version to perform any overridden code provided by the portlet author.

There are some major additions in Portlets over Servlets.

Customization Feature

Here is the feature which is completely different than Servlets. Every Portal Server has an inbuilt database where it stores all the information related to a user. Thus all Portal Server have a login page. These data are called as portlets preferences and can be accessed by program using PortletPreference object. These portlet preferences are mentioned are portal.xml file with default values. The PortletPreferences can be created or modified in processAction() method only. The Render methods can access these preferences values but cannot modify them. Generally Edit mode is used to set such preferences by the user. For example a portlet allows a person to choose different skins and colors for the portlet. This can be achieved using the edit mode of the portlet. These preferences are saved. Whenever the user will next log in he can still see those changes he made. Other then just changing of skins many other customization features can be provided by the portlet like number of records to be displayed at a time, which portlet to be kept minimized and so on.


Two part handling of Requests

Unlike the Servlets where there is only one type of request and once the request comes, it is fully processed and the response is send back to the user. In Portlets the requests are handled in two parts. One is ActionRequest and other is RenderRequest. Let us see how do these requests works.


The portlet interface declares two type of functions 1) processAction and 2) render methods. Generally a generic class implementing this interface, GenericPortlet class, is used to extend our Portlet class. It is similar to extending HttpRequest class when we are developing our Servlets. Unlike in servlets which provide with doGet and doPost..etc methods, Portlets provide us with processAction , doDispatch, doEdit, doHelp methods. To specify what type of request is send we have to create that type of URL. This can be done using createActionURL() function for actionRequests and createRenderURL() for render methods.


We know that a portal page can have output from multiple Portlets. When an ActionURL is clicked from any portlet on the page, the request is send back to the server. The Portal will first call the processAction method of this Portlet. If we require that parameters to be present in the render method also , then they are required to be set explicitly in processAction() using actionRequest.setRenderParameter() method. But when directly a render method is called, in that case the form parameters are automatically available in renderRequest object. After this the render methods of other portlets on the same page are called in any order. The sequence is shown in above diagram(from JSR168 specification doc). The selection of render method is done in doDispatch() method. Here the PortletMode(an attribute provided in actionRequest and renderRequest ) is checked of the incoming request. Depending on this, appropriate render method is called. For example, if the PortletMode is Edit then doEdit() method is called. The JSR168 provides with 2 portlet modes, doEdit(), doHelp(). But custom modes are also available depending on Portal Vendor, generally config is available. The render methods are used to generate the html fragment output for that portlet.

Portlet Session
There are several portlets on a page. Each maintains its own Portlet Session. Thus Portlet Session is of two types. One is in Portlet Scope. The values are set in this session are available through out the session of a particular portlet. The other scope is Application Scope. The values set in this Session Object is available is to all the portlets in an application. Thus the values are shared among all the portlets in the application. The portletContext object is used to access the corresponding Portlet Session. With knowledge of previous and this point one can understand a more deeper aspect called “Inter-Portlet Communication”.



Inter-Portlet Communication
Sometime there are requirements that on some action in one portlet window the changes should be reflected in other portlet window. Such functionality can be achieved using the Inter-Portlet Communication Mechanism. One of the way to achieve this is through setting the parameter in session of Application Scope. Let us say on click on of PortletA window we need to see the changes in PortletB window. When the action request is send from the portletA window the processRequest is called for the ProtletA first. Now one can do the corresponding processing and a parameter can set here in Application Scope. After this all the render methods of all the portlets on the page are called. Thus in renderMethod of PortletB one can check for this parameter and can do the corresponding processing. Thus the output of the windowB will change depending on the action of portletA window. Though there more advanced methods and implementations possible for Inter-portlet communication.