The following article has been written by Subbu and can be viewed online:
http://www.subbu.org/weblogs/main/2006/02/portlets_and_aj.html
"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.
Why Portlets for Ajax?
First of all, why use portlets to do server-side processing of Ajax requests. Here is why?
- Portlets are ideally suited for rendering fragments of markup. Portlets have the right programming model that lets portals aggregate those markup snippets into full pages. The only difference with Ajax is that, instead of letting a portal aggregate portlets into a full page, you let the browser do the aggregation on demand using JavaScript.
- Most useful portlets are full-fledged applications that encapsulate all the UI, page navigation, and some controller logic to drive the UI. If you want to use Ajax in the portlet's UI, it is best to process their Ajax requests within the same portlet. This makes development, deployment, and administration easy.
- Portlet containers provide a runtime for portlets. The runtime provides facilities for URL (re)writing, state management, portlet preferences etc. You may want take advantage of these while processing Ajax requests.
- Finally, portlets make plug-and-play of UI possible, and both JSR168 and WSRP 1.0 do a decent job of supporting such plug-and-play.
There is one key difference between developing portlets, and page-oriented web apps. With portlets, the requests are usually proxied through a portal (or another aggregating application, usually called as a consumer) to portlets. In this case of remote portlets that rely on WSRP1.0, the proxying goes one step further, and the requests are routed via a web services layer from the portal to portlets hosted remotely. Depending on how portlets are deployed, in most cases, browsers may not be able to send a HTTP request to portlets directly. Security restrictions may prevent such access. So, creating URLs correctly is important, and JSR168 and WSRP 1.0 provide ways to create URLs."
JAXFront Shortcut Solution:
The fact that it is hard to implement AJAX based portlet communication with JSR-168, we have decided to implement a direct AJAX to servlet communication for all browser based AJAX requests within JAXFront.