AJAX and Java: Toolbox

by Robert Cooper

After monkeying around with some DIY Ajax stuff, I started looking at some of the emerging tools out there. Please forgive me if I don't mention [insert project name here]. Honestly, I have played with a number of them. No, I haven't put all of them completely through the motions. However, there are a few that I think are pretty great.

Target Audience: Pretty typical Struts developer looking to enhance functionality without radically redefining the way she builds software.

Ascendancy: Order of invasiveness to your app.

AJAXTags


AJAXTags is a simple JSP taglib that offers some nice functionality. It is not a framework. It is not a methodology. It is, simply, a handful of app-friendly tricks that you can stick into your application. They have a nice demo page demonstrating each of the tags. There is a nice "sliding doors" CSS tabset, an autocomplete widget and a bean-bound table (imagine that :P). If you are like me, a lot of this is stuff that you have built by hand already, but having some standard tags for it is handy.

Taconite


Taconite uses the word "framework", but I wouldn't go that far. The short version is it is a tool that simplifies (a) making your XmlHttpRequest call and (b) gives you server-side markup that controls basic insert parameters.

For instance: If you want a button to append something to the bottom of a content area:

<script><!--
function foo(url){
var ajaxRequest = new AjaxRequest(url);
ajaxRequest.sendRequest();
}
//--></script>
<button onclick="foo('runButton.action?id=bar');">

Then your JSP for runButton would have:

<taconite-root xml:space="preserve">
<taconite-append-as-children
contextNodeID="idOfNodeToAppendTo"
parseInBrowser="true">
<div style="font-weight:bold;color:orange;">
Taconite says: Hello World!!!
</div>
</taconite-append-as-children>
</taconite-root>

Of course, with some clever breaking up of JSPs, it is not hard to use the same content set for an AJAX and Non-AJAX version of your app.

Direct Web Remoting


The Zipperheads have a nice intro to this. This is the most invasive of anything here. This is basically an easy way to expose a service bean to a web client through JavaScript directly. If you are like me, and tend to build your business services with Axis SOAP in mind, you will find it nearly brain-free to re-expose them as a DWR "JavaScript Service".

Moo.fx


This is just some chrome for your app, but its not bad and is a small and noninvasive way to give your app some polish. It is a set of nicely animated transitions and visibility controls. They have some fancy demos, but if you look at the test page you can see all the individual functions laid out pretty well.

8 Comments

debradley
2005-11-29 10:13:52
DWR invasive??
How are you defining invasive? I can add a jar and a little bit of config to my app and suddenly I have full access to the service-level classes that already exist in my class? I was thrilled to find out how easily I could add those capabilities without changing any existing code. To me that's the opposite of invasive.
debradley
2005-11-29 10:14:32
DWR invasive??
"service-level classes that already exist in my class" should (maybe) obviously be "service-level classes that already exist in my app"
kebernet
2005-11-29 10:20:25
DWR invasive??
Sorry, perhaps I was a little unclear there.


It is definitely not invasive w/r/t your service beans. However, working with your services directly from the client implies (at more than one level) that you are actually building a whole fat-client-style functionality into the HTML/JavaScript. As opposed to AJAXTags or Taconite where even your presentation layer can remain mosty unchanged from a vanilla HTML/Struts app.


DWR is might cool, but if you are attempting to retrofit an application with AJAX functionality, extensive used of DWR does require a rethinking of your presentation layer.

kebernet
2005-11-29 10:21:17
DWR invasive??
/used of/use of/g
tcowan
2005-11-29 13:34:09
AJAX replaces JSP tags
I consider the tags/jsp stuff to be more invasive, or unnecessary. DWR can be utilized with simple HTML...and if done correctly can apply behavior to HTML elements via their id or css class.




With AJAX there's really less room/need for JSP tags or JSF. I suspect the functionality in AJAXTags could be redone as a .js include and some type of binding to regular old HTML dom elements.
kebernet
2005-11-29 14:25:07
AJAX replaces JSP tags
Again, however, the reason I categorized DWR as "invasive" is you have to start with a fresh perspective on the entire UI. What AJAXTags gives you is a clear path for easily retrofitting an existing web app, especially those composed from Tiles or even simple includes, with a path to AJAXy chrome without a radical rethink.


Moreover, if it is important that your app have non-AJAX support, building an app with DWR means you effectively have to reimplement the whole UI layer for the flat version.


You are, in fact, correct about AJAX tags. Indeed, much of its functionality is enclosed in non-invasive JavaScript. This, however, is an advantage. For example: if you encounted one of its standard sliding-doors tabsets on a cell phone or via Lynx, you would not be lost. Building similar functionality with DWR is certainly *possible*, however, requires more code lifting.

debradley
2005-11-30 10:19:34
DWR invasive??
O/T, but wouldn't it be nice if you could edit your comments here?
koehn
2005-11-30 20:37:40
JsOrb
For the whole nine yards, try JsOrb (http://www.jsorb.org, http://sourceforge.net/projects/jsorb/). You get full access to your business logic via dynamically generated remote proxies, POJO entity marshalling to/from the browser, and support for binding your POJO instances to HTML elements.