Early this year I have blogged about the problems related to portlets using Ajax to update their UI from the client side, and my attempts at addressing those. See here and here. As I mentioned in those posts, I also tried to make the model a part of the JSR-286 API. Here is an update of where things stand now.

Every other web developer that I talk to is trying to figure out how best to use Ajax in their apps either to provide some slickness to web apps, or to avoid total page refreshes. In most cases, writing the server side processing code is trivial. You can use JSPs, servlets, struts, JSF or whatever to process Ajax request, and return data (as XML) or markup (as HTML) fragments. Writing client side scripts is where all the fun is. But when it comes to portlets, server side processing for Ajax requests gets tricky. Portlet related standards like JSR168 and WSRP 1.0 do have some limitations in supporting server-side processing of Ajax requests. These specs leave out a few details that limit the use of portlets to process Ajax requests and return data or markup. Read on, if you are interested in finding out what works, what does not and why.

When the JSR168 effort was started, its primary goal was to offer a standard programming model, and avoid proliferation of proprietary programming models for creating portlets. This JSR almost achived these goals when the first version of the Portlet API specification was released two years ago. But it is now at the verge of getting fragmented. I think it is time to take notice.