This document provides an introduction to Java standard portlets. It begins by discussing the limitations of traditional servlet and JSP architectures. It then introduces portals and defines portlets as pluggable user interface components that can be aggregated and displayed within a portal. The document outlines the portlet lifecycle and details the request and response processing. It also discusses portlet modes, window states, filters, and inter-portlet communication. Key advantages of using portlets over traditional web applications are highlighted.

1. Introduction to Java Standard Portlets
R O H A N FAY E
1

2. Contents
World before portlets
A typical JSP based architecture
Limitations with application based on Servlets / JSP
Rise of portals – the introduction
Portal and Portlets
Examples
Advantages
Portlet Lifecycle
2

3. Contents (contd.)
Portlets Request and Response
Java Portlet Specification
Portlet modes and window states
Portlet filters
Inter Portlet Communication
Code Walkthrough
Q&A
References
3

4. World before portlets
Conventional approach
Static HTML
Dynamic web applications
◦ Servlets and JSP technologies
Examples
4

5. A typical JSP based Architecture
5

6. Limitations with application based on Servlets / JSP
Following are the notable drawbacks of the Servlets and JSP based web
applications:
User can view and has access to the single web application at a time
Lack of content aggregation
Limitations to the content configuration and customization per user
Lack of different application modes
Lack of Window states support
6

7. So how to deal with
this? Are we not at our
best in the business??
7

8. Rise of portals – the introduction
Need of a real application, which itself will act as a base engine
Container for other integrated applications
Secure and robust API
Cost effective
Developer friendly
Ease of use
8

9. What is a portal?
A portal is designed to be a single web-based environment from which
all of a user’s applications can run, and these applications are integrated
together in a consistent and systematic way.
9

10. Gotcha! Then what is a portlet?
Portlets are pluggable user interface software components that are
managed and displayed in a web portal.
Produce fragments of markup code that are aggregated into a portal.
Displayed as a collection of non-overlapping portlet windows, where
each portlet window displays a portlet
Resembles a web-based application that is hosted in a portal.
Portlet standards are intended to enable software developers to create
portlets that can be plugged into any portal supporting the standards.
10

11. For example…
11

12. Advantages
Portlets have additional characteristics that make them different from
Servlets.
Portlet Modes
Window States
Portlet Preferences
Standard Inter Portlet Communication (IPC)
◦ Public Render Parameter
◦ Events
Resource Serving
◦ AJAX Support
◦ Binary data support
Portlet Filters
12

13. Wonderful! This will
definitely enhance the way
we do business and attract
more customers!!!
I smell money… $$$
13

14. Portlet lifecycle
init() : Initializes the portlet
render() : Renders the content
processAction() : Called when the user performs the action
processEvent() : Called when an event has been triggered
serveResource() : Called when a ResourceURL is requested
Destroy() : Releases the portlet object so it is eligible for garbage
collection.
14

15. Portlet lifecycle (contd.)
init phase – The init() method is called by the Liferay portlet container
during the deployment of the project. This method is typically used to
read initialization parameters from the portlet.xml.
Render phase – During the Render phase, the portlet generates content
based on its current state. The Render phase is called on all of the
portlets on a page when that page is rendered. Portlets typically enter
the Render phase as a result of page refresh or after the completion of
the Action phase.
Action phase – The portlet enters the Action phase as a result of the
user interacting with that portlet. Specifically, the user interaction
should result in a change of the state in the portal. Only one portlet can
go through the Action phase during single request/response cycle.
15

16. Portlet lifecycle (contd.)
Event phase – The Event phase is used to process any Events triggered
during the Action phase of the portlet lifecycle. Events are used for Inter
Portlet Communication (IPC).
Resource Serving phase – This phase allows portlets to serve dynamic
content without the need calling the Render phase on all the portlets
on the page. In Portlet 1.0, portlet requests always returned a full portal
page.
Destroy phase – This method gets called by the Liferay portlet
container when it is removed from service. This phase allow to release
any resources.
16

17. Portlet Request and Response
17

18. Java Portlet Specification
The Java Portlet Specification defines a contract between the portlet
container and portlets and provides a convenient programming model
for Java portlet developers.
◦ JSR 168
◦ JSR 286
18

19. JSR 168 (Portlet 1.0)
The Java Portlet Specification V1.0 introduces the basic portlet programming model with:
Two phases of action processing and rendering in order to support the Model-ViewController pattern.
Portlet modes, enabling the portal to advise the portlet what task it should perform and
what content it should generate
Window states, indicating the amount of portal page space that will be assigned to the
content generated by the portlet
Portlet data model, allowing the portlet to store view information in the render
parameters, session related information in the portlet session and per user persistent data
in the portlet preferences
A packaging format in order to group different portlets and other Java EE artifacts needed
by these portlets into one portlet application which can be deployed on the portal server.
Portal development is a way to integrate the different web-based applications for
supporting deliveries of information and services.
19

20. JSR 286 (Portlet 2.0)
It was developed to improve on the short-comings on version 1.0 of the
specification, JSR-168. Some of its major features include:
Inter-Portlet Communication through events and public render
parameters
Serving dynamically generated resources directly through portlets
Serving AJAX or JSON data directly through portlets
Introduction of portlet filters and listeners
20

21. Portlet Modes
Each portlet has a current mode, which indicates the function the portlet is
performing
All Java Standard compliant portals must support the View, Edit and Help
modes.
Portlet modes are defined in the portlet.xml file.
Custom modes may be created by developers.
View Mode – Typical portlet is first rendered in View Mode.
Edit Mode – When the user clicks on the “Preferences” icon, the portlets
switches to Edit mode.
Help Mode – When the user clicks on the Help icon, the portlet switches to
Help Mode.
21

22. Window States
Window States indicate the amount of space that will be assigned to a portlet.
All Java Standards compliant must support minimized, maximized and normal.
Minimized Window State – When the user clicks on the Minimize icon, only the
portlet titlebar is displayed.
Maximized Window State – When the user clicks on the Maximize icon, the portlet
will take up the entire width of the page, and become the only portlet rendered on
the page.
Remove Window – When the user clicks on the Remove icon, the portlet is removed
form the page.
22

23. Portlet Filters
Filters are Java components that allow on the fly transformations of
information in both the request to and the response from a portlet.
They allow chaining reusable functionality before or after any phase of
the portlet Lifecycle:
◦
◦
◦
◦
processAction
processEvent
serveResource
render
Modeled after the filters of the Servlet specification
23

24. IPC (Inter Portlet Communication)
Inter-portlet communication (IPC) is a technique whereby two or more
portlets on a portal page share data in some way.
In a typical IPC use case, user interactions with one portlet affect the
rendered markup of another portlet.
24

25. IPC - Importance
IPC becomes important with Portlet applications which are composed of
more than one portlet for their functionality.
Consider a banking application with one portlet at the top screen which
allows users to search for customers.
When a customer is selected, a portlet on the bottom of the screen
shows a list of that customer’s information and associated bank
accounts.
With IPC this functionality can be done in a standard way-and the two
portlets don’t even need to be on the same portlet page.
25

26. Achieving IPC
The Portlet 2.0 standard provides two techniques to achieve Inter
portlet Communication :
◦ Public Render Parameters
◦ Server-Side Events
26

27. Public Render Parameters
The Simplest method for developer to perform standard IPC.
A developer can declare a list of public render parameters for a portlet
application in portlet.xml:
The parameter names are namespaced to avoid naming conflicts..
</portlet-app>
<public-render-parameter>
<identifier>foo</identifier>
<qname xmlns:x="http://foo.com/p">x:foo2</qname>
</public-render-parameter>
.
.
</portlet-app>
27

28. Public Render Parameters (contd.)
Portlets must declare which public render parameters they want to read
by using supported public-render-parameter element :
<portlet>
<portlet-name>Portlet A</ portlet-name><
<supported-public-render-parameter>
foo
</supported-public-render-parameter>
</portlet>
28

29. Public Render Parameters (contd.)
A portlet can read a public render parameter by using:
◦ request.getPublicParameterMap()
Public parameters are merged with regular parameters so
can also be read using:
◦ getParameter(name)
◦ getParameterMap()
A portlet can remove public render parameter by invoking:
◦ response.removePublicRenderParameter (name)
◦ portletURLremovePublicRenderParameter (name)
29

30. Server-Side Events
Very powerful and highly decoupled method for IPC.
Uses a producer-listener pattern.
◦ One portlet generates an event.
◦ Other portlets may be listening and acting upon it.
Allows communication between portlets in different applications.
Additionally the container may also generate its own events.
◦ No Specific container has been standardized yet.
But beware of the added complexity.
30

31. Server-Side Events (contd.)
Portlets can publish events from its processAction code.
Publishing an event causes one or more invocations of the new
processEvent method in this or other portlets.
From the implementation of processEvents new events may also be
published .
Note that there is no guarantee in the order of delivery of events.
31

32. Code walkthrough
32

33. Questions, comments or suggestions?
33

34. Thank You!
References:
Liferay in Action – Manning
http://en.wikipedia.org/wiki/Java_Portlet_Specification
http://www.developer.com/java/web/article.php/3891786/Portlets-vsServlets-Request-Processing-with-Web-Components.htm
34