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:
It's all about Comet, we want Comet everywhere we can put it, but we want to isolate the icky bits of fiddling with pages with JavaScript. We're kind of wed to the Dojo implementation of the client-side bit, so we may as well use more of the Dojo widgets for a richer UI. For us, "works best with" needs to pay a certain amount of consideration to "fits naturally with", if you understand what I mean. I know that any framework that lets you spit out raw HTML will let you hand code in your Dojo / Comet, but that's certain to become very tiresome very quickly.
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.
Are there any other Java-based web frameworks that support easily creating Dojo widgets and working with Comet? Keith Donald tweeted that Spring MVC has Dojo support. However, I believe it's only for widgets and it still requires you to write JavaScript. If your framework doesn't have Dojo/Comet support, how hard would it be to add it?
Update: I also posted this question on LinkedIn. Make sure and check my question for additional thoughts from folks.
If the primary concerns are Comet, avoiding writing javascript, and integration with dojo, your clients might want to look at DWR3, currently at RC1, if their timeline allows them to wait for/help push towards a DWR final release. While I have yet to try out DWR3 myself, two new features listed on the Release Notes:
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 #
We're using JQuery + RESTEasy (JAX-RS) for our rich UI needs. We moved away from DWR because or UI folks didn't want to deal with a proprietary JavaScript API. They preferred JSon/XML data that worked well with their favorite JavaScript API. JAX-RS worked for us because it was "pure" data, although it can be used as an HTML MVC framework. We went with RESTEasy implementation because of the Spring Integration and Java RESTful Client. RESTEasy also does have Comet support.
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...
Spring JavaScript integrates Dojo 1.2 and provides a JavaScript API over-the-top of it for decorating HTML elements with .js behavior unobtrusively. There are 3 types of "decorations" as we call them: a WidgetDecoration that allows you to integrate any Dojo widget into your application, an AjaxEventDecoration that lets you to turn plain HTML links into XHR requests unobtrusively, and a ValidateDecoration for applying client-side form validation (preventing form submits to the server when there are validation errors). It is a simple library that is easy to introduce on a project, and one that promotes a clear separation between content, style, and behavior in your pages.
Now, Spring Faces builds on Spring JavaScript and adds a set of JSF component tags that encapsulate the JavaScript--for projects where JSF is the right choice. Yes, if you want plain MVC views -- say JSPs with perhaps Tiles for layout -- you'd be authoring Spring JavaScript directly [which is quite elegant, unobtrusive, and object-oriented, mind you].
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.
There is no special Comet support in Spring JavaScript at this time.
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.
-mike
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.
Most of the Cometd stuff for Wicket is based on wicketstuff-push, which was written by Xavier Hanin (Ivy) and Vincent Demay. I did the migration from Dojo 0.4 to Dojo 1.1 and wasn't very much involved in the Cometd stuff itself. Currently you can do two things with a cometd response: execute pure JavaScript or trigger a Wicket Ajax call. Hence, there will always be two server roundtrips to keep state updated.
@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.
Other thoughts:
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.
Regards, Stefan
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.
However, when you are building a browser-based rich internet application you probably want to use a sophisticated JavaScript MVC framework like Sproutcore, which I can really recommend. I have written about the 2 styles of web applications these days: http://www.kleineikenscheidt.de/stefan/archives/2008/10/2-ajax-styles-enriching-web-apps-vs-rich-internet-apps.html
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
http://code.google.com/p/jstm4gwt/
Screencast-Showcase-Demo
http://www.gwtwindowmanager.org/jstm/jstm4gwm.htm
HF GL
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
Features:
Posted by Lance on June 25, 2012 at 07:50 AM MDT #