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…
Categories: JavaUncategorized
9 Comments
Colin · 03/12/2008 at 16:51
That seems to be about where I’ve managed to get to with my investigations into squeezing together wicket, dojo and comet.
I think I need to override the default behaviour so that my own custom JavaScript is included, rather than the CometdDefaultBehaviorTemplate.js, but I’m still figuring that out.
The best idea that I can come up with is that this kind of stuff should all be wrapped up into a single wicket component, with all mark up, java code and javascript tightly coupled in one place.
jesse · 03/12/2008 at 17:18
right…it is kinda a tough nut, to leverage cometd better you would have to start wiring in smarter javascript into the client, but that is what lots of people are trying to get _away_ from by using a web framework like wicket.
it probably has to be a new project that leverages something like cool dijit components, backed by cometd for all data and then a wicket structure or special marked up pojo behind that..with toJSON() and fromJSON() methods.
which is a tough pill to force someone to swallow
Matthias Wessendorf · 28/01/2009 at 10:24
I am working on a JSF-based framework (ADF Faces) and our integration with the “push” does what your examples do as well. We stream, on events, some data/JavaScript calls to the client. During the incremental rendering of the page, the JS is executed and we *inject* the data on the server. We don’t trigger some server-side callbacks for that. Which seem to cause (too much) extra round trips.
Matthias Wessendorf · 28/01/2009 at 10:25
sorry, typo. We inject the data on the client!!! :))
Frank Silbermann · 28/04/2009 at 16:09
Wicket assumes the HTTP-based request/response approach; its AJAX capability merely refines that. Clean architecture minimizes deviations to the basic paradigm, so despite the inefficiency it makes sense to limit server-push in this way.
To make server push as efficient and natural as client pull you should start with a protocol designed to be bi-directional in the first place (such as general socket-based networking) with a technology that is just as hospitable to execution logic on the client as on the server.
However, firewall issues motivate us to use a protocol that runs over HTTP; deployment issues motivate us to use a developer-friendly general-purpose client programming language that is translated into JavaScript. Therefore, it seems to me that GWT would be a better basis for a web framework intended to make heavy use of COMET.
jesse · 28/04/2009 at 16:34
Certainly a fair point and I would easily concede that GWT works well with comet having done it myself in the past. But the fact remains that a lot of people really like the traditional server side content generation approach a la wicket or countless others. When you already have all your developers well versed in this sort of technology its not exactly easy, nor necessarily a good idea to shift everyone into unknown (to your organization) technology.
So adapting something like wicket to provide small reusable widgets, gadgets, components, or whatever you want to call them for server push oriented updating of information on a page can be a real win for those sorts of organizations. I suspect that in the future wicket will work on a tighter integration for this sort of support so that as you say the architecture can be clean and relevant to the future.
Mark · 07/04/2012 at 20:38
hi greg,i’m interested in using jetty’s nintocuations, but it’s a little confusing for me because i only have a few months of ajax experience. can you clarify something for me please?i’m not using cometd as i don’t need an open to my server.here’s my scenario (without cometd):1- user sends a request2- request is suspended’3- dao layer process4- dao process completes5- resume’ and send datahow do i do this with nintocuations? should i be using nintocuations or does jetty take care of suspending the thread while resources are used by the dao layer, and then resume when sending data back to the requester?also, do i have to use cometd to use nintocuations?thanks,ted
Frank Silbermann · 28/04/2009 at 19:08
My gut tells me not to expect much in the way of COMET-based components in Wicket.
Wicket’s advantage is that you can use the object-oriented features of Java to easily create business-specific custom components. Logic that executes on the client in Wicket’s AJAX components is carefully encapsulated “as is”, with the expectation that the average developer will not touch it (much like _all_ the logic of a JSF or ASP.NET component).
The client-side logic of a COMET-based Wicket component would likely also be as take-it-or-leave-it rigid. You’re never going to have the object-oriented flexibility of Wicket with client-side code unless the client-side programming environment is as smooth as Java. That is _not_ the case when programming in HTML/CSS/XML/DOM and nonstandardized-JavaScript.
Now, if Wicket’s AJAX components were implemented _using_ GWT to generate their client-side JavaScript, I might change my mind!
floristeria · 09/04/2012 at 18:04
Ted,I’m not sure what you mean by open your server . There is no rieneremqut for projects that use cometd to be open source.Jetty never suspends a request for you. You have to decide to suspend your self. Typically I would not recommend suppending for a DAO layer as there are no async JDBC implementations that you can use to take advantage of this . Instead I would suspend on a JDBC connection pool if there were no connections available this is what the QoSFilter is for.You don’t have to use cometd to use continuations.
Comments are closed.