. 49
( 87 .)


As a result of completing the portlet application wizard the Poll project
is created (see Figure 15-14). The project is shown in the Project Navigator
view. It is created with the correct directory structure for a Web application,
and so you can generate a deployable WAR ¬le simply by selecting the Poll
Portlet project and using the export function (File ➪ Export ➪ WAR File).
The appropriate portlet project build class path is also set when the project
is created. The project properties view shows the Java build path along with
other project metadata and preference settings. The properties view can
be opened by selecting the project in the Project Navigator then selecting
File ➪ Properties.
In addition the portlet deployment descriptor and Web deployment de-
scriptor are created and the deployment descriptor editor is opened. We
will take a closer look at this editor and the generated values next.

Deployment Descriptor Editor
Click on Portlet Application in the editor to see the portlet application de-
tails (see Figure 15-15). The display name for the portlet application is the
name you provided to the wizard. The application unique identi¬er (UID)
WY009-15 WY009-BenNatan-v1.cls May 11, 2004 14:50

292 Chapter 15

Figure 15-15 Portlet deployment descriptor editor.

is a generated value based on the portlet package and the portlet class
name provided to the wizard. The major version and minor version default
to 1 and 0 respectively. These values are used to track portlet application
Expand the Portlet Application and select the portlet. Its details are shown
in Figure 15-16. Like the portlet application, the portlet name was provided
to the wizard. The portlet ID is a generated value and the major and minor
version values are the new portlet defaults.
The servlet name is set as the full class name of the portlet class. This value
must map to the servlet name in the Web deployment descriptor. Using the
wizard to create the deployment descriptors ensures that this mapping and
the mapping between the abstract and concrete portlet de¬nitions are set
The portlet cache defaults are to always expire and be nonshared. The
portlet de¬nition also includes the window states that are supported, the
markup types supported, and the portlet modes supported. As we have
seen, the Poll portlet will require con¬gure and edit modes as well as its
view mode. We could have speci¬ed this in the wizard but let™s make the
change here. Click None in the column labeled Con¬gure on row labeled
HTML, and from the drop-down list that appears select Fragment. Do the
same for the column labeled Edit. This will enable our portlet to have icons
for these three modes on the portlet menu bar.
WY009-15 WY009-BenNatan-v1.cls May 11, 2004 14:50

WebSphere Portlet Development Environment 293

Figure 15-16 Portlet application details.

There are no portlet con¬guration parameters set through the wizard but
any of these values can be set here. Any con¬guration parameters set here
are speci¬ed as init-param™s in the Web deployment descriptor. This editor
will modify both the portlet and web xml ¬les.
Click on Concrete Portlet Application in the editor. The details view shows
the concrete portlet application display name and its associated UID (see
Figure 15-17). Both of these values are derived from input values to the
wizard. The wizard does not capture portlet application context parameters
but they can be set using this editor.
Expand the Concrete Portlet Application and select the concrete portlet de¬-
nition (see Figure 15-18). Here the supported and default locales are de¬ned.
The portlet title, short title, description, and keywords (for search function)
are speci¬ed by language. The concrete portlet settings are also de¬ned here.
WY009-15 WY009-BenNatan-v1.cls May 11, 2004 14:50

294 Chapter 15

Figure 15-17 Concrete Portlet Application details.

The Poll portlet will require portlet settings but we will de¬ne them later.
Close the deployment descriptor editor and save the changes.

Generated Source Code
Review the PollPortletSessionBean and the PollPortletView-
Bean classes that were generated. The Poll portlet will not use these classes
so they can be deleted.
The PollPortlet class will now have a number of errors that are dis-
played in the task view as a result of deleting those bean classes. Open the
source editor on PollPortlet.java. Let™s start our Poll project devel-
opment with a fairly empty portlet. Delete the getSessionBean method.
We will put our portlet constants in a separate class so delete the static
instance variables. Change the doView() method to remove the refer-
ences to PollPortletSessionBean and PollPortletViewBean. We
will use the JSP tags to generate the PortletURIs so delete them as well. Simi-
larly clean up the actionPerformed method and remove the getJSPEx-
tenstion method. Also, delete the JSP ¬le and its directory structure. So
our very basic PollPortlet looks something like Figure 15-19.
WY009-15 WY009-BenNatan-v1.cls May 11, 2004 14:50

WebSphere Portlet Development Environment 295

Figure 15-18 Concrete portlet de¬nition.

In this chapter you reviewed the WebSphere Studio development environ-
ment. You learned about the capability of the Portal Toolkit and the value
it brings to Studio for portlet development.
We introduced a sample application that we will develop using Studio.
You used the portlet application generation wizard to help create our port-
let project. You saw that the wizard was very helpful in creating the Portlet
Project with the correct directory structure, setting the correct class path for
the portlet project to build correctly, and creating the deployment descrip-
tors needed for our portlet application. The wizard also generated portlet
WY009-15 WY009-BenNatan-v1.cls May 11, 2004 14:50

296 Chapter 15

Figure 15-19 PollPortlet.

Java code as a starting point. Some of that we removed to leave a very
minimal base on which to build.
In the next chapter we will develop our Poll portlet using this starting
WY009-16 WY009-BenNatan-v1.cls May 11, 2004 14:50



Portlet Development

This chapter explores in detail the implementation of the example Poll port-
let. In the previous chapter we introduced the WebSphere Studio develop-
ment environment. Using the Portal Toolkit in Studio, you used the portlet
application wizard to create a portlet project and create the portlet deploy-
ment descriptors.
The complete source code for this portlet is available for download. Most
of the key sections of the portlet code are shown in listings here and from
the discussion and code shown, you should be able to create the portlet
implementation in your Studio project. However, not all of the project code
is shown here. You may want to import the completed project in Studio to
have the total reference available while you follow the discussion.
This implementation is based on the IBM Portlet API. In the following
chapter we will use this base portlet implementation and modify it to use
the JSR 168 API. While doing that we will compare the differences in im-
plementation and functionality.

Poll Portlet
Recall the description of the Poll portlet from the previous chapter and
the associated screenshots. This is a relatively simple portlet but still has
enough complexity to demonstrate some key aspects of the Portlet API.
Action event processing
Page navigation within the portlet
Multiple portlet modes”view, edit, and con¬gure

WY009-16 WY009-BenNatan-v1.cls May 11, 2004 14:50

298 Chapter 16

Portlet con¬guration parameters in PortletSettings
User customization parameters in PortletData
Database access
Trace logging
While this example portlet is simple, we will still employ good principles
to its design. We will structure the application to ensure good separation of
components based on areas of responsibility. The portal architecture itself
provides a good foundation for portlet designs. Consider how a Model“
View“Controller (MVC) pattern would apply to this portlet.
We would implement the View components as JSPs, one for each of the
portlet pages shown in the previous chapter. The Model or domain compo-
nents are minimal for our portlet. These components represent the business
objects and logic of the application domain and for our portlet that is a
small set of objects such as a Poll object or a User object. The Controller
component of a portlet is the portlet class. It is responsible to respond to
user requests from the View components and invoke behavior in the Model
components. Our portlet requires access to a persistent store and therefore
has components for infrastructure components as well.

Implementing the Controller
Open the Poll project in WebSphere Studio that we created in the last chapter
(see Figure 16-1). Use the portlet perspective. In this project you should have
a PollPortlet.java ¬le in the JavaSource directory in the package
called com.ibm.sample.poll.portlet. This is the portlet class. The
name of the portlet class was speci¬ed when you ran the portlet application
wizard and is now de¬ned in the Web deployment descriptor. Open the
source editor for this ¬le.
First consider the implementation for the doView method. This method
gets executed when our portlet is asked to render itself in view mode. The
portlet should display either the view with the question and answer choices
or the view with the voting results depending if the user has already voted.
You have not yet created our business objects or broker classes, so you have
to ¬ll in those pieces next. But the doView method can look something like
the following:
* Render the view mode
public void doView(PortletRequest request, PortletResponse response)
WY009-16 WY009-BenNatan-v1.cls May 11, 2004 14:50

Portlet Development 299

Figure 16-1 The Poll project in WebSphere Studio.

throws PortletException, IOException {

// Get the poll bean
PortletSettings portletSettings = request.getPortletSettings();
String persistType = portletSettings.getAttribute(PERSIST_TYPE);
String datasource = portletSettings.getAttribute(DATASOURCE);
String pollName = portletSettings.getAttribute(POLL_NAME);
Broker broker = Broker.getInstance(persistType, datasource);
PollBean pollBean = broker.getPoll(pollName);


. 49
( 87 .)