Portlets

Due to submitting some Portlet code for an interview I am looking at the background of portlets which will help me explain how the code works. I found a link to Manning where first you sign up for a free sandbox account and then can download a free ebook on Portlets. There is also the JSR 168 specification. I have found a white paper from Sun on the specification.

Anyway below are the basics from all the different sources I've looked at.

What are Portlets?
There are lots of definitions stating that portlets are puggable user interface components that are managed and displayed in a Web Portal. A Java Portlet is a Java Servlet that operates inside a portal. It processes requests from a portlet server and generates dynamic content.

A Web Portal is a site on the web that provides personalisation capabilities. It provides capabilities such as personalisation, single sign on and aggregation of data from different sites so it is displayed on one site, the web portal.

A portal server provides common services such as application connectivity, integration, administration, and presentation that would be required across all portal environments. Functionally, a portal server serves the portlets to the user.

Advantages

• Render JSP pages and subclass the Servlet API so developers who can write servlets and JSPs can easily write portlets.
  
• Build in support to automatically render different JSP pages depending on device
• Ability to handle messaging and events
• Customerisation both on a user group level by an administrator, and a user by user level by the user.
  

Disadvantages

• Complex user interfaces do not translate well to portlets as portlets render JSP pages on many devices certain scripting languages don't work on every device.
  
• User interfaces containing constantly updated material will not work well with portlets as when one portlet is updated all portlets on that page are updated.
• Highly interactive user interfaces do not translate to portlets as if you change one thing you will have to redraw the entire portlet page or use a scripting language to redraw the page.
  
• Portlets need to live within their "box" as pop up boxes and frames are not allowed. For example if a portlet takes you to a link outside the portal then it is hard to get back to the portal.
  
• Portlets are not fully standardized so if you develop code for one portlet server it may not work on another server.
• Portal Servers use lots of memory
  

JSR 168
This specification is suppose to standardise how portlets are to be developed on different portal servers. It covers:

Container Contact
Methods-

init()	called when the portlet is inistantiated by the container
destroy()	called when the container destroys the portlet
processAction()	called after user submits changes to the portlet
render()	called whenever the portlet is redrawn by the desktop
doView()	called by render() when the portlet is in View mode and contains logic that displays the view page of the portlet.
doEdit()	called by render() when the portlet is in Edit mode and contains logic that displays the edit page of the portlet.
doHelp()	called by render() when the portlet is in Help mode and contains logic that displays the help page of the portlet.

Portlet Mode and Window States
There are three main portlet modes:

• Edit
• View
• Help

Plus optional portlet modes such as print, which lays out a portlet for printing, and config, that lets an administrator configure portlets for groups of users.

The render() method uses the portlet mode to decide which lower level method to call.

There are 3 window states

• Minimized
• Maximized
• Normal
  

The window state indicates the amount of portal page space that will be assigned to each portlet.

Portlet Preferences
Customised behaviour for users or groups is stored as a name-value pairs in using the PortletPreferences interface.

Packaging and Deployment
Porlets are packaged as Web Archives (WAR) files like other J2EE applications. Portlets have their own deployment descriptor, portlet.xml, which describes standard elements for portlet configuration.

Security
The portlet.xml lets a flag be turned on that restricts portlet access to HTTPs. The JSR 168 also states that vendors can add authentication to query user information by role or group.

JSP Tags
Portlets have their own tag library.


IBM portlets
IBM has addition functionality compared to the portlet specification JSR168 these are:
Request/Response Object
The request/response object that the portlet receives in the render call is the same as the one received in the action call there as in JSR 168 these are two different objects
Portlet communication
Events can be sent between portlets in the same page which is not in the JSR 168 spec.
Portlet menus
Lets the portlet contribute content to a menu bar to facilitate navigation through portal pages which is not in the JSR 168 spec
Invalidation based caching
Lets the portlet explicitly invalidate cached content which is not available in the JSR 168 spec.

JSR 286
This specification now up to version 2.0 is currently under review. This specification incorporates J2EE 1.4 and integregates any other JSRs relevant for portlet development.