Dojo/Comet support in Java Web Frameworks
This week I'm doing a research project for a client. The main purpose of the project is to find out which Java-based web framework works best with Dojo and Comet. Here's the key requirement from the client:
The candidate frameworks they asked me to look at are Wicket and Tapestry 5. They're willing to upgrade to Struts 2 since they're already using Struts 1. However, they don't feel that action-based frameworks naturally lead to rich UIs, so they'd prefer a component-based framework. They're currently using Seam for an administration-type application and feel it's too heavy for their customer-facing application.
Here's what I've found so far in my research. Please let me know if anything is incorrect.
- Tapestry 5 doesn't have Dojo or Comet support (Prototype and Scriptaculous are the baked-in Ajax frameworks).
- Struts 2 has old (version 0.4.3) and somewhat deprecated Dojo support. The developers seem to be in favor of removing it and promoting people hand-code Dojo instead. Struts 2 doesn't have support for Comet.
- Wicket has support for Dojo 1.1 that includes Comet support. This was written by Stefan Fußenegger and posted to the mailing list last month. I e-mailed Stefan and asked him about documentation. His response: "I lost my ambition to document it properly since I didn't receive any feedback on the mailing list. :)"
At this point, it seems that if the client really wants to use Dojo, they should use Wicket, and possibly pay Stefan to document it properly. However, they're willing to consider other options, as long as they have Comet support.
One option I thought of is to use DWR and its Reverse Ajax/Comet support. Another option would be to add better Dojo support to Tapestry 5. However, I don't think this is possible since the Prototype/Scriptaculous code is generated by the framework and would likely require a changes to switch it to Dojo.
Update: I also posted this question on LinkedIn. Make sure and check my question for additional thoughts from folks.
Posted by greg on December 18, 2008 at 06:18 PM MST #
Are they sure they *really* want this?
Keep in mind that Comet means keeping connections open. While this can help with response time having huge amounts of long connections open is what will break you neck when you try to massively scale the site.
Always use the right tool for the job. Making Comet the number one requirement does not sound like a wise way of making a decision. I would talk to the customer about this.
Just my 2 cents
Posted by Torsten Curdt on December 18, 2008 at 07:11 PM MST #
Jersey has also proven to work well with Dojo and Comet: http://weblogs.java.net/blog/caroljmcdonald/archive/2008/10/dojo_rest_comet_1.html
JAX-RS is pretty much action based, but we don't mind it too much :).
Posted by Solomon on December 18, 2008 at 07:50 PM MST #
That "they don't feel that action-based frameworks naturally lead to rich UIs, so they'd prefer a component-based framework" suggests that they haven't really thought about this, so I would recommend that you do.
For a really rich DHTML-based UI, you want that UI to live in the client, and to talk to the server when it needs data. What you don't want is to have two separate UI models, one in the client and another one in the server, so that you are constantly making requests back to the server to sync up those two models.
So-called component-oriented frameworks are actually based on defining a server-side model for a UI that will live in the browser, and almost by definition require the kind of syncing referred to above. On the other hand, when your UI lives in the client, what you want is exactly an action-oriented framework to handle your data requests, because you won't have component state that's shared between client and server.
Posted by Martin Cooper on December 18, 2008 at 08:37 PM MST #
People either love that the built-in Prototype support works so seamlessly, or hate that they feel locked in. A goal for 5.1 is to create a sufficient abstraction layer that it will be possible to choose Prototype, jQuery or Dojo.
Cometd support has its own challenges; Tapestry is pretty well wedded to a request/response cycle, not a response/response/response/... cycle. I'm not sure how the other frameworks approach this.
Posted by Howard M. Lewis Ship on December 18, 2008 at 08:53 PM MST #
Well, I'll provide some more info on what Spring provides today...
In the Spring 3.0 timeframe, we expect to provide additional tags for applying decorations in an automated manner; for example, one thing we are working on is a tag to apply validating Dojo widgets based on domain model validation rules.
Posted by Keith Donald on December 18, 2008 at 09:58 PM MST #
I don't think they necessarily need to choose a framework based on existing comet integration. I mean they could, but depending on your needs it could be a matter of a day or two to create the initial structure of how you'd want to interact with it on client and server.
I spent a couple days a few months ago following the jetty 6 bayeux client examples (and brushed up on some protocol details from http://cometdproject.dojotoolkit.org to fix a few bugs we found in http://code.google.com/p/flexcomet) in order to integrate it in to our project.
I think we have a servlet startup listener which syncs up with our core IoC layer in the beginning in order to create an easy sort of "MessageBus" service which extends BayeuxService to broadcast and route out messages to whatever channels they need to go to.
Once that basic connection is in there and your code is able to run within the same transactional / etc boundaries as anything else it's pretty easy to make it do whatever you wanted to use comet stuff for. The jetty library is already jetty-independent if you want to use it in other containers from what I remember reading. (it's in a separate jar so it must be! ;) )
Would probably cost a week or so of time, unless my ideas on how you'd use it are overly simplistic. I also haven't had to make this app scale massively yet, so I wouldn't consider my opinions from that perspective.
Posted by Jesse Kuhnert on December 18, 2008 at 10:50 PM MST #
Why would somebody that wants to build rich client UIs want a server-side java web framework to begin with? Can't they build their UI using dojo widgets on their page and get the server-side to emit json.
Posted by mike on December 18, 2008 at 11:04 PM MST #
I'd agree with Mike and Martin.
It sounds like they would want something in the vein of a SOFEA, and to me, that implies they probably don't want a component framework on the server side.
Now, depending on what they're sending in those comet messages, they may not want an Action framework either. It's hard to tell without a bit more details.
Posted by Tim Vernum on December 19, 2008 at 12:25 AM MST #
Posted by Michael Sparer on December 19, 2008 at 02:07 AM MST #
Hi Matt, thanks for giving credit.
@Howard M. Lewis Ship
I'm pretty sure that this approach (2 others) would also fit into Tapestry. One could surely port the server side cometd code of wicketstuff-dojo-1.1 to Tapestry as it is mostly free of Wicket related code.
1) Not every application has to scale. I use Wicket and cometd on a application serving >30k visitors and >100k Wicket pages a day. The applications runs happily on a single budget server. And I don't think that much applications will exceed those numbers.
2) Using cometd with a component based framework isn't comparable to building a pure Dojo applicaton. Yes, you'll have to sync state between server and client, but that's an acceptable price to pay. Especially if cometd isn't much more than a nice enhancement to your page.
Posted by Stefan Fussenegger on December 19, 2008 at 02:48 AM MST #
Like I said in my reply on your LinkedIn question, I think you don't always need to chose a web framework. You can go with exposing a service layer and just keep your widgets on the client.
A web framework like Wicket or Tapestry can come in handy when you want to take advantage of static typing, want to organize your code in easy to manage reusable bits, and e.g. when you can't go Ajax all the way but instead also have to support the traditional web interaction model.
As for which web framework to choose, I would look at which framework makes it easy to plug in your technology of choice (Dojo in your case), and spend a few days to implement exactly what you want.
Using an action/ model 2/ web mvc framework for Ajax only applications is a bad idea imho, because it gets you the worst of both worlds; no static typing, reuse etc, and still a lot of UI code on the server.
Posted by Eelco on December 19, 2008 at 02:53 AM MST #
Posted by bamdad dashtban on December 19, 2008 at 04:31 AM MST #
Posted by Ignacio Coloma on December 19, 2008 at 11:19 AM MST #
To all those advocating, that you don't need a web framework anymore: I think this pretty much depends on what you want to build. If you are building a document-centric web site (when you have web pages), you want to use a server-side MVC framework (like Spring MVC, Tapestry, etc.) and enrich the website by using a JS library like jQuery, etc.
Regarding Comet: I have been using DWR from 1.x to latest 3.0 release candidate and I found it very good for enriching web apps. However, in my current project (using SproutCore) I found out, that DWR is not as flexible as I needed it. So I was currently looking into the Java implementation of Cometd (http://cometdproject.dojotoolkit.org). Atmosphere is probably another candidate I look into.
Posted by Stefan Kleineikenscheidt on December 19, 2008 at 12:38 PM MST #
Posted by Eelco on December 19, 2008 at 12:54 PM MST #
Since this has turned into a "You can solve your problems much easier with X instead of y"-thread, I will add another interesting link, also it does not solve the "dojo comet problem".
Java Shared Transacted Memory for GWT
Posted by Sakuraba on December 20, 2008 at 02:05 AM MST #
Posted by Toby on May 17, 2011 at 07:39 AM MDT #
FYI, I have integrated tapestry and cometd here: https://github.com/uklance/tapestry-cometd
Posted by Lance on June 25, 2012 at 07:50 AM MDT #