Blog Entry

Back in September, Jonas http://www.kryos.com/website/kryosblog.nsf/d6plinks/JSR-286" title="blogged">bloggedabout whether or not JSR 286 was our savior.  It was a good question.  And now we have the answer – kind of.   The guys at the OpenPortal Project were kind enough to build a 2.0 container for us to play around with.  I’m not going to through all the new features in depth, but you can read about it http://jcp.org/en/jsr/detail?id=286" title="JSR 286">here and http://www.ibm.com/developerworks/websphere/library/techarticles/0803_hepper/0803_hepper.html" title="here">here.  If you haven't had the chance to go through it, I'd highly recommend it before continuing.   I  was able to get a hold of the container and build some of my own 2.0 (jsr-286) portlets.  Here’s what I’ve found:

Portlet 2.0 is a social animal.  That’s right.  Version 2.0 is definitely makes talking to other portlets easier.   Finding ways to communicate with other portlets in version 1.0 was like trying to get a geek to (successfully) pick-up a super-model at the bar.  Portlet 2.0 certainly provides the communication mojo one needs.  How does it do this?  Events.

Jonas mentioned this last time out as well.  I had the chance to take it for a test run.  While I don’t particularly like having to declare every event in xml (and you don’t have to, but it’s recommended), I can see why it’s needed.   This is really taking a page from the rich application model – which is really good thing in this case.  It was desperately needed.  In fact, any new communication model would suffice.  If that doesn’t gives you the sense of how much needed it was, I don’t know what would.   It would have been nice to have a similar model driven by AJAX, but saying it and doing it are two different things.  It’s no easy undertaking, especially if you consider how one would control states if portlets could asynchronously update.   That could be a specification in and of itself.  With that being said, an accompanying AJAX framework specification would have been nice, but with DOJO and other notables in the field, I expect some further development down the road before we see some unification between javascript and server-end communication streamline. I guess we’ll have to wait, but it’s not like AJAX wasn’t considered.  

The Portlet 2.0 spec allows for a unique type of request – resource.  This means that a portlet can make a request to the portal to serve resources – synchronously or asynchronously.  This allows portlets to serve up information, such as attachments in a simple straight forward fashion without forcing the portal to process multiple render requests for any other portlets on the same page.  This also means that the portlet can handle ajax calls directly.  No more sidekick servlets needed.   Sorry Robin, Batman’s working alone now.   The serveResource method also makes the portlet context available.  This bridges the request with the portlet and portal so it’s possible to leverage portal services as well.  Even Robin couldn’t do that (at least, not without a lot of help).

One other thing that I got to test was shared render parameters.  This is where a parameter is made public to every other portlet on a given page.   This adds a nice touch to the level of personalization and customization we can do on any given page.  Stephan Hepper (JSR-286 lead) gave the best example of how this works:  a weather portlet wants to display the weather of a selected city. It therefore uses the public render parameters for encoding the zip code. The user now adds additional portlets on the page that also have zip code as one of their public render parameters, like a map portlet displaying the location of the city and a tourist information portlet displaying tourist information for the selected city.

As you can see, there’ve been some very nice enhancements to the model.  In all honesty though, it feels more like 2.0 is playing catch-up to other web 2.0 technologies than contributing something new.  No doubt, many of you that have worked with JSR 168 portlets had to extend the framework to support functions similar to what’s offered in 2.0.  It doesn’t introduce anything really innovative or ground-breaking, but in the end we must remember that it is a specification after all.  In that respect, it delivers functionality that was desperately need to make portal all the more valuable.