jesse's weblog

Cometd + Wicket

First off, I think I like wicket, its a pretty neat framework and it has some pretty solid integration with ajax which is interesting. I have to say though that having spent a lot of time on the whole long polling, ajax push, cometd type of communication approach the whole idea of ajax polling back to a server for a bit of content seems kinda quaint.

Some things I like about wicket are that you work in java for all the pages and models, etc and you still let html pages and css and all that kinda stuff work for those people that like working with them for layout, etc. There is no xml configuration for anything, things are woven together in the java which is pretty nice to work with. I did have a chuckle at Martijn Dashorst's ApacheCon08 presentation where a major feature of wicket was that there was no xml configuration. Seems like not long ago that was a preeminent feature of coolness in application frameworks.

After playing around with a few wicket examples I had to start looking into how wicket and cometd could work together. Enter the awesome wicketstuff project and the recent efforts of Rodolfo Hansen with the wicketstuff-push project. This is a pretty neat initial foray into meshing two great things together. For the cometd integration, the current status of things is that cometd is being used as a notification mechanism more then anything, not really a conduit for information transfer as in more traditional cometd apps. In the chat example provided, you click on the message and it makes a wicket ajax post back to the server, where the response has listeners attached for cometd notification, the message is taken in and cometd pushes out to all of the attached clients that something has happened and then the browser makes a wicket ajax request to get the updated information.

So its a chatty endeavor, but as for melding the convenience of a more traditional web framework like wicket with cometd its not _terrible_ by any means. It really does highlight one of the fundamentally hard problems with something like cometd in my mind. It is not hard to use cometd and get the benefits of the server push to client when your working with a lot of javascript on the client, that environment is very suitable for processing json based information returned in cometd messages from a server. Javascript is simply awesome for that kind of processing, but when most of your brains (web framework) live on the server is it harder to 'push' out that sort of information since formatting and data presentation isn't specifically managed on the browser. For example, the wicketstuff-push example doesn't use cometd to bring the actual text of any chats from the server, instead it 'wakes up' the client and the client calls back with wicket ajax and gets back dom statements to execute to 'update' the chat box. In the normal cometd examples all of that information is getting returned in json markup and then evaluated by javascript.

I am not really sure what the answer is there, perhaps as cometd continues to gain more momentum as a protocol then we'll end up with generic cometd enabled ajax components for web frameworks like wicket. That might be pretty cool...

Posted at 08:58AM Dec 03, 2008 by jesse in Java  |  Comments[7]