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.


Newbie to Portlets

My brother asked me one simple question,” how are portlets different?”. He has some know how of servlet technology but was completely unaware of the portlets technology. As a portlet programmer, I started with all the architectural features and technical jargons. But realized that it was a bit too heavy for him. From there comes the idea of posting this article explaining and starting with the very basics of Portlets.

I plan to divide this talk in two parts. First let me discuss about the differences of portlets with respect to Presentation Perspective. The second part will deal with more technical part of how this data, which is to be presented, is created in Portlets or in other words how the requests are handled in Portlets.

Presenting Data generated by Portlets
The presentation of data in portlets is different than servlets. The snapshot (ibm portal snapshot -figure 1.) gives us the first idea of portlets presentation.

The whole display is divided into Containers and Pages. Each Page can have many Containers. Page can contain output of more then one portlet. These are put in different containers on the page. One can see the different boxes in figure, each represent different portlet output. These boxes can have the functionality of a window i.e. they can be minimized or maximized. Thus one can visualize it as having multiple windows on the same page. Function wise also it is similar, when minimized the fragment of that portlet is not rendered only the title bar is shown. Similarly when maximized only the content of that portlet is shown and all the other portlets content on the same page is not shown at all.

The output of the portlets are in form of fragments. They should not contain any "html" or "body" tags, nor any "html header" information. Now comes very important questions that how this display is created. Each portal vendor provides with an Interface for configuration. Here one can create new pages. Can add containers to a page and can form a layout of the page. In second step one selects a portlet for these containers or pages. Thus one can anytime change the layout or change the portlet from which the output is coming without writing a single line of codeJ. One can even configure the rights for each page i.e. only a particular user can have the rights to see particular page. That I will discuss in more detail in the second part of talk.

Other then window modes the boxes can have more icons. These are known as portlets modes. JSR168 allows three modes that is view, help and edit. But customs modes are also allowed depending on portal vendors. Generally configure mode is also present. These modes are generally used to set the portlet preferences data. I will talk in detail about the portlet preferences data when I will talk about customization of portlets, in my upcoming articles. Similarly I will be discussing about how one can do action in one portlet like search and the result can be viewed in other. This is called as Inter-Portlet Communication.

But as for time-being the points to be taken from here by a newbie of portals are The portlets display:
  • Supports multi-window concept.
  • Supports fragments of data and not "html header" and “html” or “body” tags.
  • Shows icons for window and portlets modes.
  • Over all Page lay out can be configured.
  • Portlets from which data is generated can be changed easily.
  • Made up of containers and pages.


Future of Web Frameworks in Portlets

A lot of discussion has been going on regarding the future of several current web-frameworks in portlets. The servlet developers are already familiar with these frameworks such as Struts, JSF, Tapestry, Spring and so on. I was surfing the net and found an interesting article.

It is based on Stan Silvert presentation on JSF and portlets in Javaone.

Does JSF is the only web-framework that can get in sync with the portlets technology?


Migrating Towards Portlets

The web application development is at the threshold of another revolution. We have witnessed such a migration in past, that was from CGI to Servlets. Servlets with its multi-threaded concept have virtually captured the market. We can see a similar migration from Servlets to Portlets technology in near future.

In this Blog-spot I would be sharing the knowledge about portlets and related technologies.