Comparing JSR 168 and the IBM Portlet API

This section gives a high level comparison between the new JSR 168 Portlet API and the IBM Portlet API. First, it covers the concepts that are similar; then, it explains some of the differences between the two.


Similarities


The following features are very similar in JSR 168 and the IBM Portlet API.

















































Feature Similarities Differences
Portlet modes Both support the basic portlet modes: Edit, Help, and View. The config mode is optional in the JSR 168. The other optional JSR 168 modes (About, Edit_defaults, Preview, Print) are not supported by the IBM Portlet API.
Window states These window states are supported: Maximized, Normal, and Minimized. The Solo window state is only supported by the IBM Portlet API.
Portlet lifecycle The lifecycle life cycle is the same: init, process requests, destroy. none
Request processing Request processing is divided into an action phase for processing user actions and a render phase for producing the markup. none
URL encoding Both support creating URLs pointing to the portlet or to a resource. none
Include servlets/JSPs Servlets and JSPs can be included in the portlet. none
Portlet session Portlets can store transient information that should span requests in a session. none
Portlet application packaging Both package portlet applications as WAR files with an additional deployment descriptor called
portlet.xml
.
The
portlet.xml
format differs.
Expiration-based caching The portlet can support expiration based caching. The APIs use different mechanisms to implement this functionality. The IBM Portlet API uses a polling mechanism where the portal queries the portlet for how long the markup will be valid, whereas in the JSR 168 the portlet can attach an expiration time to each created markup. Sharing the cache entry across users is only possible in the IBM Portlet API.

Differences


JSR 168 and the IBM Portlet API differ in the following ways.






















Feature
IBM Portlet API
JSR 168
Portlet application entities Lets you define an abstract
portlet application and different instance of this portlet application as
concrete portlet applications via the deployment descriptor. This allows
reusing settings of the abstract portlet application and only overwriting
the parts that are unique for each concrete portlet application.

The deployment descriptor follows the web.xml deploymentdescriptor
and defines one portlet application and the portlet definitions for this
application.


Portlet entity There is one portlet object instance per portlet
configuration in the Web deployment descriptor. There may be many
PortletSettings
objects parameterizing the same portlet object according
to the Flyweight pattern, provided on a per-request basis. Changes in the
PortletSettings apply to all portlet instances
of this concrete portlet. The user can also have personal views of concrete
portlets that are rendered using the PortletData
for customization of the output.
PortletSettings
and PortletData are merged
into one object called PortletPreferences.
Request/Response objects The request/response object
that the portlet receives in the render call is the same as the one received
in the action call.
In the JSR 168 these are two
different objects.

Exclusive to JSR 168


These items are only available in the JSR 168.



















Feature Description
Render parameters Render parameters
allow the portlet to store its navigational state.

Render parameters stay the same for subsequent render requests and only
change when the portlet receives a new action. This enables bookmarkability
and solves the browser back button problem.
Global HttpSession scope Portlets can store data not
only with the visibility of the portlet, but also with the visibility of
the whole Web application.
Redirect Portlets can redirect to other
Web resources in the action phase.

Exclusive to the IBM Portlet API/p>

The following concepts are only available in the IBM Portlet API.






















Feature Description
Eventing Events can be sent between portlets.
Additional lifecycle listeners Lifecycle listeners besides
action and render, (such as begin page) are not available in the first version
of the JSR 168.
Portlet menus Lets the portlet contribute
content to a menu bar to facilitate navigation through portal pages.
Invalidation based caching Lets the portlet explicitly
invalidate cached content.

References


1. Comparing the JSR 168 Java Portlet Specification with the IBM Portlet API by
Stefan Hepper

Filed in:
5 Comments To ' Comparing JSR 168 and the IBM Portlet API '

dan said...

Big Brother 6: The Final Veto, the Final Three
Tonight's show was pretty good. Janelle's private talk last time with April successfully planted ... The veto competition involved a rather convoluted structure that basically boiled down to knowing more about the ongoings of the house and the former HouseGuests than any other player.
found your blog - good work Play poker tip the most popularity game anywhere

Mary Morgan said...

A real enlightening blog. Don't stop now. Here's the resolve a lot of people are searching for; how to buy & sell everything, like music on interest free credit; pay whenever you want.

ADRENALINE JUNKIE. said...

Nice blogg, Thanks for letting me visit and leave a comment. By the way I made this great webpage on stopping comment spam that you might find usefull. If you do could you please link to me so everyone will know. Blogging

Blog Babe said...

Hey, you have a great blog here! I'm definitely going to bookmark you!

I have a xxx pornstar Check It Out!

Jerry Simpson said...

A real enlightening blog. Don't stop now. I'm sure you'd be interested in How to buy & sell everything, like music on interest free credit; pay whenever you want.

Post a Comment