Portlet 2.0 - JSR 286 Final Release

The second version of the Java Portlet specification has been finally released. JSR 286 hit its final release milestone, yesterday, June 12, 2008.

I am not on any JSR mailing list, so I don't know for certain what held up the final release, but I'm glad to see it's finally here. I hope this means we'll start seeing a flood of portals and Portlet containers start shipping releases of their products/projects with official JSR 286 support. Matter of fact, it was the release announcement by JBoss that led me to discover JSR 286 had gone into final release.

Some of you might not be aware of what the differences are between JSR 168 and JSR 286. Unicon has done two presentations at the JA-SIG conferences covering this material. I encourage you to look at them for some more in depth coverage (JSR 286 presentation from St. Paul 2008 JA-SIG conference, JSR 286 presentation from Atlanta 2006 JA-SIG conference). I'd like to highlight a few of the features I'm most looking forward to working with here.

My Favorite JSR 286 Features

Resource URLS

Resource URLs give you the ability to do things similar to what I discussed previously here and here. The main idea, is your Portlet wants to serve some content besides the HTML snippet that goes inside their box when the portal renders the entire portal page. This content might be an image (as shown in the previous examples) or might also be a JSON stream for AJAX capabilities.

Event Dispatching

One of the things that was impossible to do with the old JSR 168 specification, was to have two Portlets in two different web applications communicate with each other. You were either forced to put both Portlets in the same web application and use the Portlet Session APPLICATION_SCOPE or creat your own ad hoc system outside of the JSR 168 specification. While I can appreciate the developer ingenuity at solving things like this, I'm much happier that the new Portlet Specification has given us an official way to communicate between Portlets.

Portlet Events are like events in most other contexts. You had an event type and your Portlets can either listen to that event type or not. Portlets are allowed to generate events and listen to events. There is a new lifecycle phase for event receiving that will occur after the Portlet action phase and before the render phase.

Setting Markup Head Elements

One of the late changes to the spec was giving Portlets the ability to provide markup fragments for the head element of the resulting Portal HTML page. This will now allow Portlets to get markup added to a portion of the page they previously didn't have access to. So, instead, developers were forced to modify the Portals they were using to accomplish the same thing. Hopefully, this allows some Portlet developers to get out of the business of modifying the Portal, just to accomplish certain things with the Portlet they are writing.

Caching Changes

The caching ability in JSR 168, was limited to a simple number of seconds to cache this portlet output. There are two big changes with respect to caching that should really improve the world of Portlet caching. One, is you will now be able to use Validation Key based caches. This gives the Portlet the ability to decide whether the cache is valid or not, instead of relying on the Portal to know that. The Portlet can look at the Portlet state, determine if anything has changed, and if not, report that the validation key is correct, instead of re-rendering itself. This should lead to some performance improvements on the more complicated portal pages out there. The second change, will help even the non-complicated portals. You will now also be able to mark a Portlet as being cacheable system-wide. So instead of having the output of a portal be cached for each user, you can say a certain Portlet is the same for ALL users in the system. This will be a huge improvement for portals that have some shared content that all users receive, but doesn't change on a per user basis.

Other Interesting Things in JSR 286

There are some other changes in JSR 286 which are probably significant, I just don't think they will change my life as a Portlet developer very significantly.

Public Render Parameters

I've never been a big fan of Portlet Render Parameters. However, I will admit they do simplify the development required for simple Portlets. Render Parameters are now being enhanced, to allow sharing across Portlets. For example, if you want to use a custom City. You could set a Public Render Parameter on the City parameter and share that between multiple portlets for the same user. Then, if the user updates the value in one Portlet, all the Portlets will now see the new updated value. This could be achieved in a more complicated way using Portlet Events, but for the simplest cases, Public Render Parameters will be much easier.

Portlet Filters

If you've ever used Servlet Filters in the Servlet world, then you have a pretty good idea what benefits Portlet Filters bring the the table of a Portlet developer. I guess the main reason I am not as excited about them as most has to do with using Spring Portlet MVC for most of my Portlet development. In the Spring framework you get this concept because of the structure of the framework itself. You can use Spring MVC Interceptors to do the same thing. However, if you're not a Spring Portlet MVC user, then you might have been waiting for Portlet Filters.

Window ID / Namespacing Consistency

Another change that I actually think is really important, is the improvements being made to the concepts of Portlet Window ID and Namespacing. The JSR 168 specification had some discrepancies between a feature available in the Portlet Tag Library, but was not available to the Portlet class itself. This namespace tag, was very important if you did any kind of JavaScript work at all. If you used JSP files for rendering you were ok, you had access to the Tag Library, but if you chose to use any other view technology, you were out of luck. Now the Portlet code will have access to the same namespace information. Additionally, this namespace is tied directly to the Portlet Window ID. This window id uniquely identifies an instance of a portlet, per user, per subscription, per login session. This was a concept more Portlet Container implementations supported, you could even argue the JSR 168 specification itself implied the concept as much with the Portlet Tag Library namespace tag. It's only natural then, this value be made a first class piece of data that the Portlet has access to.

Porlet Request Dispatcher from other lifecycle methods

One of the changes, I least understand how to take advantage of, is the change to allow access to the Portlet Request Dispatcher from all Portlet lifecycle methods. You use the Portlet Request Dispatcher to call either a Servlet or JSP in the same web application. This is most commonly used to delegate the view rendering to a JSP. The reason I see this as confusing, is that the other lifecycle methods (Action and Event) are not allowed to produce any render output. So, why would I need to dispatch to another Servlet or JSP for rendering? If it's simply a matter of calling a RESTful style service, I'm not sure why I need the Request Dispatcher to do that. I could make the call to the RESTful service without the Request Dispatcher. I'm sure some other developers have been waiting a long time for this, I guess I'm just not one of them.

Additional CSS classes

Some additional CSS classes have been defined by the JSR 286 specification. These new classes will certain help Portlet developers create Portlets that are both portable across Portal implementations, but also take on the look in feel of the target Portal. I'm not as excited about these changes, mainly because I still think the set of classes defined, is insufficient to meet the demands of good user interfaces. Hopefully, these will continue to expand over time, but considering how long it took JSR 286 to come out, I wouldn't be looking additional Portlet specific CSS classes any time soon.

Some miscellaneous items to help portal/web frameworks

There are some additional items in the specification I'm not going to cover here. The remaining changes are all pretty small, and seem more targeted to Portlet Framework developers who need just a little more information to help their framework work better. I'm happy to see the JCP process take into consideration the needs of the framework developers, I just don't think these changes will affect the every day Portlet developer.

What was left out of the JSR 286 Specification

There are a few items I think the new JSR 286 specification failed to address. Here are a couple of them.

Clear Read / Write AJAX support

Resource URLs are great. I love the abilities they give us for non-HTML content support. The ability to tie a JSON stream to a Resource URL is going to be a clever work around for many Portlets. Unfortunately this doesn't address all the needs a developer would have. Developers have no way to make sure other Portlets receive state change information, when updating state through a Resource URL (see section 13.1).

Improved Groups and Permissions Support

One benefit Portals bring over the average web application generally, is the support for rich groups and permissions. I think uPortal has even better support then most portals in this area. I attended a presentation by Jen Bourey about the JA-SIG Calendar Portlet she developed. This was the most recent story I heard by a developer who had to struggle through the simplistic API that the Portlet specification currently supports. Unfortunately, this did not improve.

More CSS Classes

See my previous discussion on Portlet CSS classes above.

Hopefully, the Pluto 2.0 release is imminent and we can begin working on incorporating it into the uPortal 3.1 release. I'm looking forward to the opportunities this new specification gives for developing Portlets that are both more powerful and simpler.

---- Cris J H