« Bloglines trashed all of my feeds | Main | Reunion at last? »
October 19, 2005
AJAX and Portals (and Cocoon of course)
In the last weeks several people mentioned that portals will get obsolete with AJAX - don't know if they really honestly meant this. Especially at the Cocoon GetTogether I was asked about my opinion on this topic several times. Well, at that time I never had thought about it before, so my response was not very helpful I guess. Now some weeks later I can give an answer :)
But first, AJAX is a cool technology and it helps in creating much nicer web applications. But first things first.
The basic definition of a portal is "a web application aggregating content" - this means you need a way of describing which parts you want to aggregate in order to get a page to the browser. With a portal, you have different portlets (as a simplification, let's say one for each part) and then you order/group them using the portal mechanisms. Does AJAX help you with this task? No, definitly not. AJAX runs on the client and can refresh parts of a page. But you need the description on the server before anything is send to the client.
What about rendering the decorations (title, icons etc.)? What if you need personalization and individualization? Without a portal you reinvent the wheel as AJAX does not help you at all with this. And finally, what about all these nice standards a lot of people are using today: JSR 168 and WSRP? No, AJAX has nothing to do with this. And let's not forget all the nice components comming with a portal like integrating different datasources etc.
So does this mean that AJAX is totally useless for portals? No, of course not. First, AJAX provides improved user experience, so you can (should?) use AJAX in your portlets and improve parts of the page.
But what about the portal itself? Let's see: A usual function of a portal is to minimize/maximize different parts (portlets) of the page. Currently such actions require a full reload of the page. Now if the portal would use AJAX the minimizing could be done in the client and the client just notifies the server about the action.
If the user is working in a portlet and for example submits a form, currently the whole portal page is reloaded. Again, with AJAX you could just reload this particular portlet. And if you think a little bit further, you could use AJAX for a lot of user-portal interactions, like removing portlets or reordering them (think of drag-and-drop in the browser).
So imho a portal should provide AJAX support to create an improved user experience.
Saying this, let's get to the more interesting part: I'm currently working on exactly this for the Cocoon portal (yeah, sorry it's Cocoon again). The prototype I have is currently doing only the basic stuff like minimizing and maximizing. But it shouldn't be that hard to implement the rest.
The real challenge is inter portlet communication! What happens if a change in one portlet has an influence on other portlets? In this case, you have to reload more than one portlet...but - of course :) - the Cocoon portal already keeps track of the list of portlets changed during one request, so we can even exchange all of the changed portlets using AJAX. And that's without a full reload of the page. It should be fairly easy...(ok, time will tell of course).
I think I will need some more weeks to show this as I'm currently in the process of cleaning up the Cocoon portal for the next version first. Before the AJAX stuff we will have nicer, bookmarkable urls for most portal actions and these urls will make the use of AJAX much easier.
So stay tuned...I hope to get some things running for the ApacheCon to demo during my presentation
Posted by cziegeler at October 19, 2005 06:38 PM