Using Servlets and JavaServer Pages with Portlets

119
CHAPTER 5
Using Servlets and
JavaServer Pages with
Portlets
T
HE PORTLET APPLICATION
can use servlets and JavaServer Pages (JSP) in addition
to portlets. These Java 2 Enterprise Edition (J2EE) resources can be created espe-
cially for the portlet application, or they can be part of a port of an existing J2EE
application. Existing servlets and JSP will probably need to be edited to conform
to the portlet markup rules for a content fragment. In this chapter, we discuss
using servlets and JSP with a portlet. Most portlets will use JSP or another page
display technology such as Apache Velocity to render content. Rendering content
directly from a portlet is just as awkward as displaying HTML output from a servlet.
This chapter also examines using the portlet request dispatcher, which is used
to include servlets or JSP inside the portlet. The portlet passes its render request
and response objects to the servlet or JSP, and we cover the rules and exceptions
for this pass-through. In addition, we explain how to handle any exceptions the
servlet might throw inside the portlet. You’ll also learn how to deploy servlets, JSP,
and portlets together as an integrated web application.
We are not going to cover any web frameworks in this chapter. Apache Struts 2.0
and JavaServer Faces (JSF) will support portlet applications in the future. Most
popular open source frameworks will probably release a portlet module or add-on.
The biggest architectural difference is that portlets have to handle two requests
(action and render) instead of just one (like a web application).
Portlets, Servlets, and JSP Design Goals
Most portlets should use JSP or another presentation technology (like Apache
Velocity) to display their content The JSP page can share the portlet’s session,
request, and response objects easily, and there is a portlet JSP tag library to make
some tasks easy.

In these cases, the portlet is going to act as a controller, and handle incoming
action and render requests. The render requests will be processed and delegated
2840ch05.qxd 7/13/04 12:44 PM Page 119
Download at Boykma.Com
Chapter 5
120
to a JSP page, based on session attributes, request parameters, portlet modes, or
window states. The action request handling phase of the portlet makes an excellent
place to put a front controller that handles incoming command requests, while
the
render()
method can determine which page to display.
The business logic for the portlet application should be encapsulated in classes
that do not refer to classes from the
javax.portlet
package. This makes reuse easier
in web applications, Swing applications, web services, or other portlet applications.
One factor to consider when assessing JSP reuse is that the portlet should be
using styles defined in the portal’s style sheet for all content. If your content all
shares a similar look and feel across portlets, it makes the portal seem more inte-
grated, and portal administrators can adjust the portal style sheet to reflect desired
changes. These changes could include standard fonts, company colors, or larger
default text sizes. If you reuse these JSP pages in a standard web application, you
will need to have your own copy of a portlet-API compatible style sheet in the web
application, to match the expected styles.
You also will have to be careful not to use portlet tags or classes inside the JSP if
you want it to remain portable. For these reasons, it is probably not likely that you
will be able to leverage much of the JSP pages directly for reuse. Some pages may
lend themselves better than others. Try and encapsulate some common functional-
ity into a JSP tag library that can be shared between different applications. Split the

JSP pages into chunks of portable and nonportable code.
For exceptionally large applications (hundreds or even thousands of pages),
you may want to look into a page-generation technology with templates. Using
Apache Velocity (
/>) or another page template
language, you could define certain chunks of the templates as portlet code and
other parts as web application code. A simple generation tool that calls Velocity
could generate JSP pages for both portlets and web applications, and store them
in different folders. You could also use Velocity directly within a portlet, instead
of JSP.
Portlet Request Dispatcher
Your portlet can use a portlet request dispatcher to include the content from
a servlet or JSP page. The portlet request dispatcher translates the portlet’s render
request and render response into servlet requests and responses. Then the portlet
request dispatcher passes those servlet objects to the appropriate servlet or JSP
resource. The resource processes the render request as if the request was an
HttpServletRequest
and adds its content to the portlet’s render response. Each
portlet has access to a portlet request dispatcher through the portlet’s
PortletContext
object. The portlet request dispatcher is an object the portlet container creates
that implements the
PortletRequestDispatcher
interface. Here are the two methods
for retrieving a
PortletRequestDispatcher
object from the
PortletContext
object:
2840ch05.qxd 7/13/04 12:44 PM Page 120

Download at Boykma.Com
Using Servlets and JavaServer Pages with Portlets
121
public PortletRequestDispatcher getNamedDispatcher(String name)
public PortletRequestDispatcher getRequestDispatcher(String path)
Each of these methods retrieves a portlet request dispatcher for a servlet or
JSP. The difference is how the resource is found in the web application. The
getNamedDispatcher()
method is used to get access to a servlet or JSP that is given
a name in the web application deployment descriptor. It is also possible to name
a servlet from your application server’s administration tool; this is dependent on
the application server used.
The
getRequestDispatcher()
method is used to access a resource relative to
the portlet’s context root. The
path
argument must start with a “/”, and must be
a valid path. For each of these methods, if the path or name is invalid, the methods
will return null.
The
PortletRequestDispatcher
object is very similar to the
RequestDispatcher
object from the servlet API. The major difference is that servlets may either include
another servlet or forward a request, while portlets may only include another servlet’s
response. A portlet may not forward a request to a servlet, because that means that
control would not return to the portlet. The portlet remains in control when it
includes a servlet or a JSP. When the servlet (or JSP) is finished writing output, con-
trol passes back to the portlet that included the servlet.

There is only one method on the
PortletRequestDispatcher
object:
public void include(RenderRequest request, RenderResponse response)
throws PortletException, java.io.IOException
The
include()
method hides all of the details of loading and processing the
servlet or JSP page, just like in the servlet API.
Request Dispatcher
A portlet may use a portlet request dispatcher to include the output of either
a servlet or a JSP page. This example shows how to load a JSP page called
homePage.jsp from the WEB-INF/jsp directory of your portlet application:
PortletContext portletContext = getPortletContext();
PortletRequestDispatcher prd =➥
PortletContext.getRequestDispatcher("/jsp/homePage.jsp");
prd.include(request,response);
The
include()
method on the
PortletRequestDispatcher
object throws
a
PortletException
or an
IOException
.
You may pass a query string on the path used for the
getRequestDispatcher()
method. For instance, our previous example could look like this:

2840ch05.qxd 7/13/04 12:44 PM Page 121
Download at Boykma.Com
Chapter 5
122
PortletContext portletContext = getPortletContext();
PortletRequestDispatcher prd =➥
PortletContext.getRequestDispatcher("/jsp/homePage.jsp?personalize=NONE");
prd.include(request,response);
The rule to remember is that any parameters passed in the query string to the
PortletRequestDispatcher
override any existing parameters with the same name on
the request object. This can be useful for providing temporary overrides of param-
eters for one JSP page, while keeping the portlet’s parameters intact for use on other
JSP pages and servlets.
If you would like to load a servlet through a request dispatcher, map the servlet
to a path in your portlet application’s web.xml deployment descriptor. Use the
<servlet-mapping>
element in the web.xml file, just as you would for a normal
web application. Here is a snippet of code that includes a servlet with a request
dispatcher:
PortletContext portletContext = getPortletContext();
PortletRequestDispatcher prd =➥
portletContext.getRequestDispatcher("/patents");
prd.include(request,response);
Named Dispatcher
A named dispatcher is useful for loading servlets or JSP pages that have been given
a name in the portlet application’s web deployment descriptor. It also returns
a
PortletRequestDispatcher
object. One important difference is that it is impossible

to pass a query string to a servlet or JSP that is called through a named dispatcher.
If we have a servlet named SingleSignOnServlet, we could include it when we
render the portlet, using code like the following:
PortletContext portletContext = getPortletContext();
PortletRequestDispatcher prd =➥
PortletContext.getNamedDispatcher("SingleSignOnServlet");
prd.include(request,response);
One important point is that portlets may not be included in the output of
another portlet using dispatchers. Rendering one portlet’s content inside another
portlet should be accomplished by calling methods directly to get content, providing
access to the portlet’s templates, or another form of direct access.
2840ch05.qxd 7/13/04 12:44 PM Page 122
Download at Boykma.Com
Using Servlets and JavaServer Pages with Portlets
123
Including Content in the Portlet
The content returned by a servlet should be the same type of content that the
portlet is writing out. In almost all cases, that will be character data, not binary
data. If you need to serve binary data from a portlet, provide a link directly to the
servlet from the portlet’s content. This way, your portlet application can serve
images, PDF files, and other binary data. For character data, use the
getWriter()
method on the servlet response.
Your servlet should not try to set the content type on its servlet response. The
portlet is in control of the content type, and the servlet cannot affect it. Although
your portlet sets the content type on its response, your servlet cannot get the con-
tent type from the servlet request. If your servlet works with different types of text
content (XML, HTML, etc.), you will need to manage content types with request
attributes or session parameters. You can always use two different servlet classes,
of course.

Handling Exceptions Thrown by the Servlet or JSP
Portlets will need to be able to handle exceptions thrown by servlets or JSP pages
that are included by the portlet. If the servlet or JSP throws an
IOException
, the
IOException
is passed unchanged to the portlet. Every other type of exception is
encapsulated in a
PortletException
by the portlet container.
Either the portlet may catch these exceptions itself, or it may throw them to
the portlet container, just like any other type of portlet exception.
Simple Portlet Example That Includes a Servlet
We are going to demonstrate how to include a servlet inside a portlet, using the
named dispatcher and the request dispatcher. For simplicity, we are going to have
only one servlet, and it is going to write only one line of content. We will include it
once with a request dispatcher, and once with a named dispatcher.
When you run this simple
HelloPortlet
example in Pluto, it will look like
Figure 5-1.
2840ch05.qxd 7/13/04 12:44 PM Page 123
Download at Boykma.Com
Chapter 5
124
The servlet is named
HelloServlet
in the web application deployment descriptor,
and it is mapped to the /hello URL. Here is the web.xml deployment descriptor for
our portlet application, with the servlet description and mapping:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
" /><web-app>
<display-name>First Portlet</display-name>
<description>This is the first portlet.</description>
<servlet>
<servlet-name>HelloServlet</servlet-name>
<servlet-class>com.portalbook.servlets.HelloServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>HelloServlet</servlet-name>
<url-pattern>/hello</url-pattern>
</servlet-mapping>
</web-app>
The
HelloPortlet
class is very simple. You can see how it sets up both of the
portlet request dispatchers:
Figure 5-1. Our
HelloPortlet
example showing two types of request dispatches to
a servlet
2840ch05.qxd 7/13/04 12:44 PM Page 124
Download at Boykma.Com
Using Servlets and JavaServer Pages with Portlets
125
package com.portalbook.portlets;
import java.io.IOException;
import javax.portlet.GenericPortlet;
import javax.portlet.PortletContext;

import javax.portlet.PortletException;
import javax.portlet.PortletRequestDispatcher;
import javax.portlet.RenderRequest;
import javax.portlet.RenderResponse;
public class HelloPortlet extends GenericPortlet
{
protected void doView(RenderRequest request, RenderResponse response)
throws PortletException, IOException
{
response.setContentType("text/html");
PortletContext portletContext = getPortletContext();
PortletRequestDispatcher reqDispatcher =
portletContext.getRequestDispatcher("/hello");
reqDispatcher.include(request, response);
PortletRequestDispatcher namedDispatcher =
portletContext.getNamedDispatcher("HelloServlet");
namedDispatcher.include(request, response);
}
}
Next is our
HelloServlet
class, which writes only one line to its response. We
do not include a content type in its output because the portlet already did.
package com.portalbook.servlets;
import java.io.*;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class HelloServlet extends HttpServlet

{
2840ch05.qxd 7/13/04 12:44 PM Page 125
Download at Boykma.Com
Chapter 5
126
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException
{
PrintWriter writer = resp.getWriter();
writer.write("<BR>Hello, I'm inside a portlet.");
}
}
Our portlet.xml deployment descriptor is very ordinary because it does not
describe anything about the servlet:
<?xml version="1.0" encoding="UTF-8"?>
<portlet-app xmlns=" />version="1.0" xmlns:xsi=" />xsi:schemaLocation=" /> /><portlet>
<description>Includes a Servlet</description>
<portlet-name>HelloPortlet</portlet-name>
<display-name>Hello Portlet</display-name>
<portlet-class>com.portalbook.portlets.HelloPortlet</portlet-class>
<expiration-cache>-1</expiration-cache>
<supports>
<mime-type>text/html</mime-type>
<portlet-mode>VIEW</portlet-mode>
</supports>
<portlet-info>
<title>Hello Portlet</title>
<short-title>Hello</short-title>
<keywords>Hello, Portlet</keywords>
</portlet-info>

</portlet>
</portlet-app>
Request and Response Objects
The servlet or JSP that is included in the portlet’s render response has partial,
limited access to the portlet’s
RenderRequest
and
RenderResponse
objects through
the servlet or JSP’s
HttpServletRequest
and
HttpServletResponse
objects. Many of
the servlet methods either perform no operation or return null when used inside
a portlet, because portlets have a higher level of abstraction than servlets. Other
servlet methods call the equivalent method on the portlet objects. Table 5-1 lists
the methods on the
HttpServletRequest
, and how they behave when included
from a portlet.
2840ch05.qxd 7/13/04 12:44 PM Page 126
Download at Boykma.Com
Using Servlets and JavaServer Pages with Portlets
127
Table 5-1. The Methods on an HttpServletRequest Object in a Portlet
Method Name Method Description
getAttribute() Returns the value of an attribute when given a name,
or null. Calls getAttribute() on the portlet’s
PortletRequest object.

getAttributeNames() Returns the names of the available attributes.
Calls getAttributeNames() on the portlet’s
PortletRequest object.
getAuthType() Returns the authentication scheme used. Calls
getAuthType() on the portlet’s PortletRequest object.
getCharacterEncoding() Returns null; does nothing.
getContentLength() Always returns 0.
getContentType() Returns null; does nothing.
getContextPath() Returns the context path associated with the portlet
application on the portal. Calls getContextPath() on
the portlet’s PortletRequest object.
getCookies() Returns cookies from properties on the portlet request.
getDateHeader() Returns a date header from properties on the
portlet request.
getHeader() Returns header from properties on the portlet request.
getHeaderNames() Returns header names from properties on the
portlet request.
getHeaders() Returns headers from properties on the portlet request.
getInputStream() Returns null; does nothing.
getIntHeader() Returns an integer header from properties on the
portlet request.
getLocale() Returns preferred locale for the portal. Calls
getLocale() on the portlet’s PortletRequest object.
getLocales() Returns locales accepted by the portal. Calls
getLocales() on the portlet’s PortletRequest object.
getMethod() Returns “GET”.
getParameter() Returns the value of the parameter from either the
portlet request, or from the query string passed into the
request dispatcher. The query string takes precedence.
2840ch05.qxd 7/13/04 12:44 PM Page 127

Download at Boykma.Com
Chapter 5
128
Table 5-1. The Methods on an HttpServletRequest Object in a Portlet (continued)
Method Name Method Description
getParameterMap() Returns a map of name/value pairs of the parameters
from the portlet request and the query string passed into
the request dispatcher. The query string takes precedence.
getParameterNames() Returns the names of the parameters from the portlet
request and the query string passed into the request
dispatcher.
getParameterValues() Returns the values of the parameter from the portlet
request and the query string passed into the request
dispatcher. The query string takes precedence.
getPathInfo() Returns the path and query used to get the portlet’s
request dispatcher.
getPathTranslated() Returns the path and query used to get the portlet’s
request dispatcher.
getProtocol() Returns null.
getQueryString() Returns the path and query used to get the portlet’s
request dispatcher.
getReader() Returns null; does nothing.
getRealPath() Returns null.
getRemoteAddr() Returns null.
getRemoteHost() Returns null.
getRemoteUser() Returns the login for the current user, or null if there
is no login yet. Calls getRemoteUser() on the portlet’s
PortletRequest object.
getRequestDispatcher() Same as Servlet 2.3 specification.
getRequestedSessionId() Returns the request’s session ID, or null if there is

none. Calls getRequestedSessionId() on the portlet’s
PortletRequest object.
getRequestURI() Returns the path and query used to get the portlet’s
request dispatcher.
getRequestURL() Returns null.
getScheme() Returns the name of the URL scheme used to call the
portlet. Calls getScheme() on the portlet’s
PortletRequest object.
getServerName() Returns the server’s hostname. Calls getServerName()
on the portlet’s PortletRequest object.
2840ch05.qxd 7/13/04 12:44 PM Page 128
Download at Boykma.Com
Using Servlets and JavaServer Pages with Portlets
129
Table 5-1. The Methods on an HttpServletRequest Object in a Portlet (continued)
Method Name Method Description
getServerPort() Returns an integer representing the server’s port
number. Calls getServerPort() on the portlet’s
PortletRequest object.
getServletPath() Returns the path and query used to get the portlet’s
request dispatcher.
getSession() Same as Servlet 2.3 specification
getUserPrincipal() Returns a Principal for the current user, or null if the
user isn’t logged in yet. Calls getUserPrincipal() on
the portlet’s PortletRequest object.
isRequestedSessionId Same as Servlet 2.3 specifications.
FromCookie()
isRequestedSessionId Same as Servlet 2.3 specifications.
FromURL()
isRequestedSessionId Same as Servlet 2.3 specifications; deprecated.

FromUrl()
isRequestedSessionId Returns the validity of the request’s session ID.
Valid() Calls isRequestedSessionIdValid() on the portlet’s
PortletRequest object.
isSecure() Returns a Boolean indicating secure communication.
Calls isSecure() on the portlet’s PortletRequest object.
isUserInRole() Same as Servlet 2.3 specification.
removeAttribute() Removes an attribute on the request object. Calls
removeAttribute() on the portlet’s PortletRequest
object.
setAttribute() Sets an attribute on the request object. Calls
setAttribute() on the portlet’s PortletRequest object.
setCharacterEncoding() Returns null; does nothing.
The servlet response object passed to the servlet or JSP by the portlet wraps
the behavior of the portlet’s
RenderResponse
object. Like the
RenderRequest
object,
the
RenderResponse
object is similar to its servlet counterpart. Having a firm knowl-
edge of Java servlet programming can go a long way in understanding portlet
development and best practices. Table 5-2 describes the behavior of the methods
on the
HttpServletResponse
object when a portlet includes content from a servlet
or JSP.
2840ch05.qxd 7/13/04 12:44 PM Page 129
Download at Boykma.Com

Chapter 5
130
Table 5-2. The Methods on the HttpServletResponse Object
Method Name Method Description
addCookie() Does nothing.
addHeader() Does nothing.
addIntHeader() Does nothing.
containsHeader() Returns false.
encodeRedirectURL() Returns null.
encodeRedirectUrl() Returns null; deprecated.
encodeURL() Returns an encoded URL for URL rewriting for session
tracking.
encodeUrl() Returns an encoded URL for URL rewriting for session
tracking; deprecated.
flushBuffer() Flushes the buffered output to the client for the
response body, and commits the response.
getBufferSize() Returns the size of the response buffer.
getCharacterEncoding() Returns the character encoding used by the MIME
body for the portlet’s response.
getLocale() Returns the portlet response’s locale.
getOutputStream() Returns the output stream for writing binary data.
getWriter() Returns a writer for writing textual data.
isCommitted() Returns true if the response has been committed.
reset() Resets the buffer and the response properties, if the
response has not been committed.
resetBuffer() Resets the buffer if it hasn’t been committed yet. Leaves
properties alone. Useful for error message handling.
setDateHeader() Does nothing.
setHeader() Does nothing.
sendError() Does nothing.

sendRedirect() Does nothing.
setBufferSize() Sets the buffer size used for the portlet’s response body.
setContentLength() Does nothing.
setContentType() Does nothing.
setIntHeader() Does nothing.
2840ch05.qxd 7/13/04 12:44 PM Page 130
Download at Boykma.Com
Using Servlets and JavaServer Pages with Portlets
131
Table 5-2. The Methods on the HttpServletResponse Object (continued)
Method Name Method Description
setLocale() Does nothing.
setStatus() Does nothing.
Request Parameters and Attributes
The request parameters from the portlet’s render request object are available in
the servlet or JSP as parameters on the servlet request object. The parameters are
named the same, and can be accessed through the
getParameter()
method on the
request object.
The same is true for attributes stored on the portlet’s render request. The servlet
or JSP will be able to access these attributes from the servlet request object.
Session Management Between a Portlet and a Servlet
or JSP
All of the resources in a portlet application share a session for each user. Portlets
will access the session through the
PortletSession
object, and servlets and JSPs will
use their
HttpSession

objects. Any attributes stored on the session by a portlet are
accessible through the
HttpSession
object, and any attributes stored by servlets or
JSPs are accessible through the
PortletSession
object.
A portlet may share an object in the session for a servlet or a JSP by putting
the object into the application scope. If the object is in portlet scope, the object
will be in a namespace defined by the portlet container, and will not be easily
accessible to the servlet or JSP. The object will still be an attribute on the session,
but it would be tricky to decode the proper name. You should avoid trying to decode
an out-of-scope attribute, because it will be container-specific—this would qualify
as a hack.
Inside the portlet, you call the
setAttribute()
method on a
PortletSession
object like this:
PortletSession session = request.getPortletSession(true);
session.setAttribute("ContentManager", contentManager,➥
PortletSession.APPLICATION_SCOPE);
2840ch05.qxd 7/13/04 12:44 PM Page 131
Download at Boykma.Com
Chapter 5
132
From the JSP or servlet, you ask the
HTTPSession
object for an attribute called
ContentManager, just as you normally would do for any other object on the ses-

sion. In a servlet, it might look like this:
ContentManager contentMgr = (ContentManager) session.getAttribute("ContentManager");
Creating a Form in JSP
Your portlet’s JavaServer Pages can use HTML forms just like stand-alone JSP
pages. The two most important portlet practices are to use the POST method for all
forms, and to set the action for the form to an action URL or a render URL for the
portlet.
The POST method is necessary because the URL’s query string may be used
by the portlet container or portal to maintain information about the user’s session.
The POST method is safe for portlets (and any servlets or JSP pages they include)
to use.
The HTML form will need to point back to the portlet that created the form
so the portlet can process the request. The portlet can create
PortletURL
objects
that can then create portlet URLs. There are two choices for creating a portlet URL:
action URLs or render URLs. Inside the JSP page, you will need to use one of the
portlet URL JSP tags to create a portlet URL. Either portlet URL JSP tag will output
a URL, so you can just include a tag into your form’s action. We discuss the portlet
JSP tags in the next section. For more on portlet URLs, see Chapter 2.
Using the Portlet JSP Tag Library
JavaServer Pages can use the portlet tag library to access portlet functionality. Any
JSP pages that are called from a portlet can use these tags to get access to portlet
objects, create URLs for links to the current portlet, or provide a unique identifier
for named HTML elements.
The recommended taglib declaration for any JSP pages that use the tag
library is
<%@ taglib uri=' prefix='portlet'%>
In your web.xml application deployment descriptor, you will need to map the
portlet taglib URI to the location of the tag library descriptor (TLD) file:

<taglib>
<taglib-uri> /><taglib-location>/WEB-INF/tags/portlet.tld</taglib-location>
</taglib>
2840ch05.qxd 7/13/04 12:44 PM Page 132
Download at Boykma.Com
Using Servlets and JavaServer Pages with Portlets
133
You do not need to add anything to the portlet.xml deployment descriptor to
enable the tag library, because the tags are for the JSP pages, which are processed
by the JSP compiler and servlet engine.
The <defineObjects> JSP Tag
The
<defineObjects>
tag is used to define several objects from the calling portlet’s
request in the JSP page. You can use these objects from JSP scriptlets. The tag takes
no attributes or content—it’s always used in this form:
<portlet:defineObjects/>
The variables it defines are
PortletConfig portletConfig
RenderRequest renderRequest
RenderResponse renderResponse
These objects are the same ones that are included in the request object for
a JSP or servlet in a portlet application. They can be accessed as request attrib-
utes from that request object. The
<defineObjects>
tag is a convenient shortcut
for using these objects from a JSP.
Here is an example that uses the
renderRequest
variable from the

<defineObjects>
JSP tag:
<portlet:defineObjects/>
The host name of the server: <%=renderRequest.getServerName()%>
We can use any of the methods available on any of the objects that are defined,
including retrieving other objects from the portlet API.
The <param> JSP Tag
The
<param>
portlet tag is used to provide parameters for the
<actionURL>
and
<renderURL>
tags. It represents a name/value pair. There are two required attributes
on the
<param>
tag:
name
and
value
. You can set these to be whatever you need for
your portlet development. Here is an example showing the
<param>
tag as part of
an
<actionURL>
tag:
<portlet:actionURL>
<portlet:param name="emailID" value="255"/>
<portlet:param name="mvcAction" value="deleteEmailConfirm"/>

</portlet:actionURL>
2840ch05.qxd 7/13/04 12:44 PM Page 133
Download at Boykma.Com
Chapter 5
134
The <actionURL> JSP Tag
The
<actionURL>
tag builds a URL that will send an action request to the portlet.
The action request takes parameters that are supplied by including
<param>
tags
inside the start and end pair of
<actionURL>
tags. The portlet container will process
an action request for one portlet, and then send render requests to the other portlets
on the page. For more on action requests, see Chapter 2.
Here is an example of how to use the
<param>
tag with the
<actionURL>
tag:
<portlet:actionURL>
<portlet:param name="emailID" value="13"/>
<portlet:param name="mvcAction" value="deleteEmail"/>
</portlet:actionURL>
In addition to the portlet parameters, the
<actionURL>
tag can take several
optional attributes. All of these optional attributes also apply to the

<renderURL>
JSP tag, which we discuss in the next section of this chapter.
The windowState Attribute
The
windowState
attribute for the
<actionURL>
and
<renderURL>
tags can be set to
one of the allowed window states for a portlet application running on this portal
container. When the user follows the link, the portlet will appear in the specified
window state, if it is a valid state for this portlet. Nonvalid states will result in a JSP
exception. The standard window states are normal, maximized, and minimized.
If the
windowState
attribute is not included, the portlet should keep its current win-
dow state. For more on window states, see Chapter 4.
If we were building this e-mail portlet, we might want the user to see the
e-mail message in the largest space available in the portlet. We tell the portlet to
use the maximized window state here:
<portlet:actionURL windowState="maximized">
<portlet:param name="emailTo" value=""/>
<portlet:param name="mvcAction" value="createEmail"/>
</portlet:actionURL>
The portletMode Attribute
The action request link tells the portlet to use a certain mode. This attribute is also
optional, and if it is omitted, the portlet will retain its current mode. The portlet
modes defined in the specification are VIEW, EDIT, and HELP. You may also use
any custom portlet modes that your portal supports. Like window states, a nonvalid

2840ch05.qxd 7/13/04 12:44 PM Page 134
Download at Boykma.Com