Build Portals using Portlets

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


|

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.

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

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


|

As you can see, the deployment descriptor specifies a single servlet that

uses the class org.apache.pluto.core. PortletServlet and is configured to load

the FirstPortlet. Also, note that the servlet is mapped to a URL pattern that

begins with /PlutoInvoker/, which is required for Pluto. The portlet application

descriptor, portlet.xml, provides a few portlet-specific details.

The element declares the name of the portlet. The element specifies the fully qualified class name of the portlet. The

element specifies which modes are supported for a given . For our

FirstPortlet, we are saying that it can generate content of the “text/html” type

and supports modes, such as, VIEW, HELP and EDIT.

Last step is to compile the Web project into a FirstPortlet.war file, which

will be used for deployment on Pluto server. Alternatively, an Apache-ant-script

based build.xml can also be used to create and deploy the .war file onto the

webapps folder of the Pluto server.We have provided the whole Web project

workspace folder for reference in this months DVD.

The content generated by FirstPortlet can be viewed on the Secondary Page once the portlet gets deployed on Pluto

Deployment on Pluto



Now that we are having FirstPortlet .war file ready, we can deploy it on

Pluto portal. Upon deployment, log into Pluto and select the Pluto Admin page
from the Navigation Menu. On this Admin Portlet, select the Secondary Page and

under Portlet applications, select the FirstPortlet application and then click

Add Portlet to complete the process. The generated portlet can now be viewed

under Secondary Page from Navigation Menu. The Pluto distribution comes with

Tomcat integration and provides a platform for the developers to test and start

up with portlet development.

Conclusion



Portlets give developers another layer of abstraction, as now they do not
have to consider what type of HTTP method the client may be using. Pluto that

comes integrated with Tomcat provides developers with a platform to test and

start up with portlet development.