Build Portals using Portlets

Portlets are bricks with which we build multifunctional portals. Pluto is a Tomcat-based portal container that helps you quickly develop and deploy portlets

Thursday, August 09, 2007

For building multifunctional portals, today developers are using portlets, which are simple, reusable and event-driven components. These portlets can be used to hold small applications or to display dynamic information based on events on a portal. Portlets can also be included in regular Web applications. For example, for a regular Web application that has a web-page that lists all music tracks available, we can use a portlet for listing the current top 5 tracks being accessed by the users of that application.

Portal, Portlets & Pluto
A portal is defined as a Web application that facilitates single sign-on, user-level customization, and content aggregation from various sources and hosts all the information over the presentation layer (web-page). Whereas a portlet is a user interface that can be plugged into a Web portal. A portlet processes requests and generates dynamic content in the form of fragments. The portal then aggregates these fragments and structures them into the portal pages. The portlet specification largely incorporates the servlet specification. Like servlets, portlets are web components that are deployed inside of a container and generate dynamic content. Container manages their lifecycle, and portlets interact with web client through request/response model. Portlets differ from servlets as they do not create complete documents but just markup fragments. Also the content generated by portlet is dependent on content being shown on portal page. For example, if the portal server is asking for html/text content then all portlets for that page should generate html/text content only. Unlike servlets, portlets are not URL addressable as they are part of a page. On the technical side, a portlet is a class that implements the javax.portlet.Portlet interface and is packaged and deployed as a .war file inside of a portlet container.

Upon logging, we see that Testsuite portlets are up. They provide tests for evaluating compliance with the portlet specification

A portlet container is very similar to a servlet container, which provides a runtime environment for portlets by providing it with necessary resources and information about its environment. A portlet container is responsible for initializing and destroying portlets and also for passing user requests to it and collecting responses. One such portlet container is Pluto that implements the Portlet API and offers developers a working platform .

Pluto is the reference implementation for the portlet specification. It is an Apache project, and is an add-on to Tomcat 4 or 5. Now, we will be using the Pluto server to develop and deploy portlets.

Configuring Pluto
We have given Pluto-Tomcat bundle in this month's DVD. Unpack it into the PLUTO_HOME directory. The bundle is a binary distribution of the Pluto container bundled with Tomcat. So the working of the Pluto server resembles with the working of Tomcat server. Also set the environment variable JRE_HOME pointing to JDK1.4 JRE, as that will be used as the default JRE by the server while starting. Now to start the Pluto server open a command line console and change the directory to PLUTO_HOME/bin and run the startup.bat command. This script starts the server and deploys the Pluto-portal driver under the PLUTO_HOME/webapps/pluto directory. It can be accessed at http://localhost:port/pluto. Also with the server starting up, a war file also gets deployed. This is the Pluto TestSuite, which contains the default portlets that verify whether the portal driver is working correctly or not. Upon logging into Pluto portal driver, we can see the portal driver running with Test Portlet 1 and Test Portlet 2 from the TestSuite.

Through the Pluto Admin page, the FirstPortlet application can be added to the Pluto portal driver

Writing your first portlet
Writing a portlet is the same as writing a servlet. There are three modes of a portlet, namely, VIEW, EDIT and HELP. In the VIEW mode, portlets provide functionality to show some information, like displaying some text message. EDIT mode allows the user to configure the behavior of the application. For example, a user of a mail application would specify his username and password in EDIT mode. Help functionality of the application comes under HELP mode.

To start up with writing the portlet, first create the Web project, which is similar to any servlet project having /WEB-INF/web.xml file, which will be used as deployment descriptor of the project. Also add the portlet-api-1.0.jar into the build path of your project. Now under the source folder, create the FirstPortlet.java file. Every portlet should implement a portlet interface. This interface defines the life cycle methods for a portlet.

public class FirstPortlet extends GenericPortlet{
protected void doView(RenderRequest request, RenderResponse response) throws PortletException, IOException
response.setContentType
("text/html");
PrintWriter writer = new PrintWriter
(response.getWriter());
writer.println("This is FirstPortlet!");
}
protected void doEdit(.....
}
protected void doHelp(...
}

The class GenericPortlet, found in the portlet.jar archive file, is a convenience class that implements the render method and defines three empty methods, doView, doEdit, and doHelp. Our example portlet FirstPortlet is a subclass of GenericPortlet and so can implement any of these methods. When the container invokes the render method, the render will call one of these methods, based upon portlet mode. For example, doEdit might prepare an HTML form to customize a portlet. doView will help generate display markup, and doHelp might build a portlet's help screen. In FirstPortlet, we are just displaying a text message, so we will override doView() method of the GenericPortlet class. In this method, we call response.setContentType() to inform the portlet, as in, what type of content the portlet will generate. Once the content type is set, you can get a PrintWriter from the response object and start writing into it. Similarly, we can define the doHelp and doEdit methods for the FirstPortlet class.

Deployment descriptors
As for the servlet project we had to write deployment descriptors, we have to write same deployment descriptors for portlets also. So under WEB-INF directory, we have to define two portlet descriptors-web.xml and portlet.xml. The first deployment descriptor, web.xml, requires a reference of Pluto's PortletServlet that helps the portal driver to serve the portlets. The following code snippet shows web.xml.

FirstPortlet

FirstPortlet

org.apache.pluto.core.PortletServlet
...


FirstPortlet
/PlutoInvoker/FirstPortlet
|

Page(s)   1  2