I was a bit surprised to see this entry JSR 286: The last portlet standard? at CMSWatch recently, because I have been working with Portals for a long time and I have seen customers waiting for JSR-286 specification due to limitations of JSR-168. Not only that, I see that customers expect more features to be added to portlet specification. JSR-268 makes the portlets work in more cohesive fashion, but it still lack the access to many common Portal services and that is what I believe would be next frontier for portlet standard.

Portlet standard were written keeping Servlet standards in mind, with the notion of Portal Containers providing services similar to what Servlet Containers did. Many servlet container services were standardized (and others are on the way to become standards), making servlets (and JSP) so popular. With portlets, you can create a self-contained application and now with JSR-286, you can interact with other JSR-286 portlets, but what about interaction with Portal itself? Other than running the life-cycle of these portlets, Portals cannot expose their services to these portlets without breaking the spec.

Take an example, I have a shopping cart portlet and I want to display a link to help from my shopping cart. This help page is hosted by portal and the only way I can access it is by hard-coding the URL. I cannot access Portal navigation services to get me the link. It becomes worse when you add the personalization and security on these navigation items. Suppose you want to show different help pages to different customers (based on their profile, spending status etc), now you would need a jump page URL on your portal that this portlet would link to, and that page can figure out which help page is the correct one for this customer. Portals can have multiple pages exposes to different users based on authorization settings, but as these settings are not exposed to portlet, you would have to find a work-around to get your application working.

It may sounds like I am beating up the specification, that is not the case as specifications evolve over the time. When customers run into issues where they have a choice to break the spec or find an alternative way to solve the problem, they are open for alternative ways, as they don’t want to live with all the constraints of spec and add some extra features, they would rather go with fully open alternatives, even if it means their code may not be portable to other Portal servers.

To solve these kind of problems, we would have to start providing more services to these portlets and that would make this standard more attractive. I am positive that there are more releases of this spec in future for us!