JSR 168 Portlet Specifications

Agenda

• What are JSR and JCP?
• What is a Portlet as per JSR 168?
• JSR168 Specifications

1. Portlet Lifecycle Methods
2. Portlet Modes
3. Portlet Window States
4. Portlet Data Models
5. Dispatching requests
6. Caching and Security.
   

• A sample Portlet.


What are JSR and JCP?

JCP – Java Community Process

The international Java community develops and evolves Java™ technology specifications using the Java Community Process (JCP).The community is involved in the definition of future versions and features of the Java platform. Since its introduction in 1998 as the open, participative process to develop and revise the Java™ technology specifications, reference implementations, and test suites, the Java Community Process (JCP) program has fostered the evolution of the Java platform in cooperation with the international Java developer community.

JSR-Java Specification Request

A JSR is a Java Specification Request. This is the document submitted to the PMO (The Program Management Office is the group within Sun designated to oversee the Java Community Process and manage the daily running of the program. The actual development of the specification occurs within the Expert Groups.) by one or more members to propose the development of a new specification or significant revision to an existing specification.

Courtesy- http://www.jcp.org/en/introduction/faq
http://en.wikipedia.org/wiki/Java_Community_Process

What is a Portlet as per JSR 168?

• General Perception
– A portal is a webpage with many different links to various applications.

• Programmer’s View
– “A portal is a web based application that –commonly- provides personalization, single-sign on, content aggregation from different sources and hosts the presentation layer of Information Systems.”- JSR 168 spec

Now we must come across a series of questions..for better understanding.

A series questions (3W and 1H)
1. What is a Portlet?
2. What is Portal Page?
3. What is the difference between a portal page with many links and a portal page with portlets?
4. How is it different from a page with lots of links?

Portlet

• “A portlet is a Java technology based web component, managed by a portlet container, which processes requests and generates dynamic content.”
-- JSR 168 spec
• A portlet is itself an application having its own lifecycle.

Portlets and relationship with Portals

• “Portlets are used by portals as pluggable user interface components that provide a presentation layer to Information Systems.”
--JSR 168 spec
• So now we know how its entirely different from a website containing a lots of links apparently called portals

So it’s obvious that portlets are the basic building block of a successful web Portal where each portlet is assigned to do some specific task and the user is able to gather maximum information on a single page. The portal itself provides the user management capability and users have the facility to single sign on to use all the facilities provided by the entire portal. Personalization is also one of the most important features a portal provides. All these things are much more difficult and developed separately on a traditional portal page which is just a page with bunch of links. Ease of “plug in and run” concept and ease of removal from the portal page gives a new age portal a winning edge over traditional portals

JSR168 Specification
• Portlet Lifecycle Methods
• Portlet Modes
• Portlet Window States
• Portlet Data Models


Portlet Lifecycle Methods

This life cycle of a portlet is expressed through the init (), processAction(),
Render() and destroy() methods of the Portlet interface. The Portal calls the init() method to instantiate the portlet. Then the browser requests are handled by the portlet using ProcessAction() method if the request involves some kind of data processing. Else the render method takes care of it by rendering the page using either doView(),doEdit() or doHelp().Remember the render method is called whenever

a. the processAction() method is called by action request.

b. the renderRequest() comes into picture which doesn’t involve data processing.

c. any other portlet on the same portal page calls the render() method.

Portlet Modes
Generally a portlet has three modes
a. View mode –normal mode to show the content.

b. Help Mode –to show a help page about the application.

c. Edit mode –to show edit page for editing the portlet preferences.

d. But a portal can also have a “custom mode” if the manufacturer wishes to have.

Portlet Window States

• NORMAL

• MAXIMIZED

• MINIMIZED

• CUSTOM –based on manufacturer discretion.

Portlet Data Models

• Portlet to store view information in the “render parameters.”

• Session related information in “portlet session”

• User persistent data in the “portlet preferences”

Portlet Request Dispatcher

• It dispatches the request to other portlets or servlets using the Portlet request Dispatcher with the only Include () method.

Caching and Security

• Portlets that want their content to be cached using expiration cache must define the duration (in seconds) of the expiration cache in the deployment descriptor.
• Security constraints are a declarative way of annotating the intended protection of portlets. A constraint consists of the following elements:

1. Portlet collection
2. User data constraint
   

Can We Design a sample Portlet with the basic knowledge about portlets….???

Binding to the BODY onLoad event in a portlet

One of the hassles that many developers come across when developing Javascript for their portlets is the lack of access to the BODY onLoad event. You can't simply override this using javascript as this might break functionality in the portal theme, or in other portlets on your page. (Ofcourse, this predicament is not limited to portlet development!)

My old trick was to use the below addToBodyOnload() javascript function, that borrowed some code from quirksmode.org:

function addToBodyOnload(oFunction) {
var existingOnload = window.onload;
window.onload = function () { oFunction(); existingOnload(); }
}

addToBodyOnload(newOnloadFunction);


The above makes use of javascript's ability to pass functions around as data and let you 'append' your function to the chain of functions called by the onLoad event by 'wrapping' these function calls. However even this has its limitations.

Sometimes, a previously existing onLoad function may require access to "this" or "event" - implicit objects in event handlers that refer to the object originating the event and data about event. For this scenario, I've tried expanding the above to handle the passing of the event object through the wrapper function. Event is handled a bit differently in different browsers - in some it is implicit, and in others needs to be explicitly passed - wheras the "this" object seems to be implicit always. Take a look at the example below:



You should see that the event and window objects are accessible to both the old 'wrapped' and new onload functions.

One last alternative... Working with WebSphere Portal 6.0 and IBM's JSF-based Ajax framework, I found that the javascript called by the page's onload event handler (via the addBehaviour() method, or hx:behaviour tag) is actually a property of another object that seems to expect values from within this object as parameters. This makes it next to impossible to automatically deduce the correct parameters to pass in from the wrapper function. In cases like this, there's another very simple workaround that is suitable for many occasions - the old setTimeOut function:

var t=setTimeout(newOnloadFunction, 100);

This above will call your function 100ms after this script is executed. Remember that this could be a bit unreliable. Putting a line like the above in your page starts the clock from the point the browser renders that part of the page. On a page that takes a long time to render, this could mean that your script fires before body.onload. There's a chance that DOM elements your script references (for example using getElementById()) may not yet be present on the page in such a scenario. For best results, put this as close to the bottom of your page as you can, and increase the time value as much as you can (although this can look glitchy if your onload event makes visual changes to the page). Also make sure you handle scenarios where the script fails to find DOM objects, perhaps by setting a new timer to go off in another 100ms time.