Dojo/Comet support in Java Web Frameworks
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.
From http://raibledesigns.com/rd/entry/dojo_comet_support_in_java
Matt Raible has been building web applications for most of his adult life. He started tinkering with the web before Netscape 1.0 was even released. For the last 11 years, Matt has helped companies adopt open source technologies (Spring, Hibernate, Apache, Struts, Tapestry, Grails) and use them effectively. Matt has been a speaker at many conferences worldwide, including ApacheCon, JavaZone, Colorado Software Summit, No Fluff Just Stuff, and a host of others.
Matt is a DZone MVB and is not an employee of DZone and has posted 45 posts at DZone. You can read more from them at their website.
- Login or register to post comments
- 2739 reads
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Jose Maria Arranz replied on Fri, 2008/12/19 - 6:35am
My proposal: ItsNat
Why?
* ItsNat has built-in Comet support: polling (AJAX timers) and long polling (server push using AJAX)
* Is AJAX intensive, your application can run entirely in the same web page (no reload). This is appropriated to work with JavaScript frameworks like Dojo.
* Runs in any servlet container including JVM 1.4 based and including Comet. An article about performance of long polling in "classic" (synchronous) application servers.
* You have absolute control of the layout using pure X/HTML/SVG templates and Java W3C DOM. This is appropriated to mix a server centric framework with a client centric (e.g. Dojo). This example shows how an ItsNat application uses the famous Syntax Highlighter JavaScript library, content of files is pushed from server and calls the syntax highlighter to render in client. This JavaScript library adds new DOM nodes in the client, this is not a problem because with some care a "dynamic zone" in client may be a static zone in server and peace for both.
* ItsNat doesn't use onXXX handlers, they are free for you. In fact these handlers can be defined in server calling Element.setAttribute(name,value) including Internet Explorer as target. The same for "id" attribute, ItsNat uses an internal "xpath" system (is not a standard XPath) mixed with a node caching system.
* In ItsNat every AJAX event returns JavaScript code, this JavaScript is automatically generated by the framework with the view changes in server (DOM changes), moreover user defined JavaScript code can be send to the client too. This is very important to comunicate/manage from server a client JavaScript library.
* ItsNat has user defined DOM events, from client user defined AJAX events using JavaScript can be sent to the server and received as W3C DOM events.
* AJAX events may be synchronous and asynchronous. In synchronous mode JavaScript code can send some data to the server synchronously (for instance using user defined events) and the server can answer executing some JavaScript code in client before the caller returns.
* With ScriptUtil.getNodeReference(node) we can obtain a string in server pointing to the required DOM node in client; this is very useful to generate custom JavaScript code from server. Client node location is faster than using document.getElementById in client because it uses the internal server and client node cache managed transparently by ItsNat. Here is an example.
By the way: the upcoming 0.6 release will add an event system to the CometNotifier (this event system is optional and complementary to the current approach of making UI changes and sending custom code in long polling Comet), and more developer control of error reporting (for instance when a session expires)
Note: some text in this message seems to fool DZone sorry if many posts have been received.
dzoneCody replied on Fri, 2008/12/19 - 9:25am
An implementation that is not specific to Dojo, but does support Comet...
http://www.icefaces.org/main/home/index.jsp
Also check out Grizzly / Atmosphere... https://grizzly.dev.java.net/
Jose Maria Arranz replied on Fri, 2008/12/19 - 11:59am
Article about scalability of long polling in synchronous app. servers.