The Portlet Lifecycle
Essentially any client request
made to the portal will result in one or more portlets
being invoked. The portlet
lifecycle is defined in the Portlet interface of the Portlet
API and provides the following
interface.
init(PortletConfig config)
processAction(ActionRequest req,
ActionResponse res)
render(RenderRequest req,
RenderResponse res)
destroy()
Initialization and Shutdown
The portlet container is
responsible for initializing all of the portlets. The
initialization may take place
once the portlet container starts up or the first time a request
is made to a portlet. If an error
occurs during the portlet initialization, the portlet is not
placed into service. Generally,
the initialization method is used to start up any resources
that are useful for the duration
of the portlet’s functioning. As an example, the creation of
a connection to a database or a
web service is often best done in the init method. The
PortletConfig object provides
portlet configuration information that has been
defined in the descriptor.
Similarly the portlet container
may invoke the destroy method when it decides
the portlet should be removed
from service. This normally happens when the portal is
being shutdown.
Request Handling
Generally in the portal
lifecycle, the portlet container will initialize all of the
portlets when the portal is
started and invoke the destroy method on all portlets when
the container is shutdown.
However while the portal is running every client request made
to the portal will often result
in one or more portlets creating a markup fragment to be
included in the final portal
page.
A request can be broken into two
phases, action handling or rendering markup.
An action request is an optional
state that can be made to change the state of the
underlying portlet application.
For instance an example login portlet would allow users
to provide their name and
password and will display a submission form to send the
supplied information to the
portal, resulting in an action request. The portlet container
will handle any action request
first before any content is generated as shown in the UML
sequence diagram. Once the action
request has completed, the portlet container generates
markup by invoking the render method
of every portlet on the page in no particular
order excepting those portlets
that have defined their content to be cached. The portal is
responsible for aggregating all
portlet fragments and displaying a full portal page back to
the user’s browser. A client
request does not have to result in a processAction invocation.
However, every client request to
the portal must go through the render phase (unless the
portlet’s content is cached).
Both processAction and render
methods supply a request and response object.
The ActionRequest and
RenderRequest objects inherit from PortletRequest, a decorator1
for a HttpServletRequest object
defined in the Servlet specification. The portlet request
provides much of the same functionality
as a HttpServletRequest object that traditional
J2EE web application developers
are familiar with as well as methods for querying the
1 A Decorator[GoF], also known as
a Wrapper is a design pattern that provides additional
functionality to an object by
sub-classing to provide additional methods and exposing
many of the same methods of the
underlying (wrappee) object. The Java stream and file
I/O classes are good examples of
decorators.
current window state or portlet
mode. The primary difference between the ActionRequest
and the RenderRequest is that an
ActionRequest may not write to the output stream, since
it is responsible only for
performing business logic.
Any event triggered within
portlet such as submitting a form or clicking a link
will result in either an action
request or a render request being made. The Portet API
provides methods for the
construction of URLs in the portal to cause either event to
occur.
