The AJAX Tag Library, a set of JSP tags that simplify the use of Asynchronous JavaScript and XML (AJAX) technology in JavaServer Pages, has been released.

This tag library offers five tags for common AJAX functionality:

• autocomplete: retrieves a list of values that matches the string entered in a text form field as the user types
• callout:displays a callout or popup balloon, anchored to an HTML element with an onclick event
• Select/dropdown: based on a selection within a dropdown field, a second select field will be populated
• toggle: switches a hidden form field between true and false and at the same time switches an image between two sources
• update field: updates one or more form field values based on response to text entered in another field

Usage of the autocomplete tag (from the online demo) looks like this: in an HTML form, a normal input field is used:

<input id="model" name="model" type="text" autocomplete="off" size="30" class="form-autocomplete" />

Then, later in the JSP page, the autocomplete tag is specified, with a reference to this input field:

<ajax:autocomplete
  fieldId="model"
  popupId="model-popup"
  targetId="make"
  baseUrl="${contextPath}/autocomplete.view"
  paramName="model"
  className="autocomplete"
  progressStyle="throbbing" />

The autocomplete.view request is resolved to a servlet that extends BaseAjaxServlet, which then returns data in a predefined format that the tag uses to populate the list, which is a fairly standard use of AJAX.

What do you think of the tag library?

I'm assuming the tags expect a response in a certain format (ex. <list><item></item>...</list> in the case of typeahead) so why should I have to construct the return format manually? Shouldn't there be an included servlettype specific to the request being made (ex. AutoCompleteServlet) provided by the framework which is extended by the developer and an associated return type for that servlettype (Ex. AutoCompleteResponse). The developer should be able to populate the reponse without having to know the protocol required to communicate back to the calling tag.

For AJAX to take off in a standard sense, we need these:

1. A server side framework that shields us from writing servlets to handle input xml and output xml (example, JSF could be integrated to do AJAX, i don't know if there is a JSF implementation that does this already)
2. A light javascript engine that provides a micro platform (probably based on micro kernel architecture) that runs on the browser, to provide standard functionality, and integration with the server framework above.
3. A standard API that lets us code javascript without worrying about the differences between browsers (atleast to an extent).

By the way, the AjaxTags library looks great and is definitely the right step in that direction.

For AJAX to take off in a standard sense, we need these:1. A server side framework that shields us from writing servlets to handle input xml and output xml (example, JSF could be integrated to do AJAX, i don't know if there is a JSF implementation that does this already)

In the JSF world most component vendors either already have Ajax functionality, or they are adding it (this includes Oracle ADF Faces and Otrix's WebGrid and WebTree). Component developers have been handling the process in different ways, but I know that MyFaces and Shale have been investigating more standardized approaches, which means we will also see more robust support in future JSF releases.

Kito D. Mann
Author, JavaServer Faces in Action
http://www.JSFCentral.com - JSF FAQ, news, and info

Are you using JSF in a project? Send your story to trenches at jsfcentral dot com, and you could get your story published and win a free copy of JavaServer Faces in Action!

For AJAX to take off in a standard sense, we need these:1. A server side framework that shields us from writing servlets to handle input xml and output xml (example, JSF could be integrated to do AJAX, i don't know if there is a JSF implementation that does this already)2. A light javascript engine that provides a micro platform (probably based on micro kernel architecture) that runs on the browser, to provide standard functionality, and integration with the server framework above.3. A standard API that lets us code javascript without worrying about the differences between browsers (atleast to an extent).By the way, the AjaxTags library looks great and is definitely the right step in that direction.

This sounds *exactly* like what we offer with WebORB:

1. WebORB is the server-side framework deployable to any servlet container. To expose your classes, simply copy them or the JAR into WEB-INF\lib or WEB-INF\classes, no need to implement any special interfaces

2. WebORB includes the Rich Client System - a light weight JS library for binding to an invoking on any Java object, web service, EJB or CFC

3. The Rich Client System provides an API to perform object binding and method invocation. Here's an example:

var webORBURL = "http://host:port/weborb";
// bind to a server object
var proxy = webORB.bind( "com.foo.Bar", webORBURL );

// invoke server object's method
var result = proxy.helloWorld();

// invoke the same method asynchronously
proxy.helloWorld( new Async( helloWorldResult ) );

// handle async result
function helloWorldResult( result )
{
  // result is what method invocation returned
}

For more info visit: http://www.themidnightcoders.com

cheers,
Terry

I have such implementstion is worked.
You can see demo on http://smirnov.org.ru/myfaces-ajax/ajax.jsf
Short description on http://smirnov.org.ru/en/ajax-jsf.html

I'll live with generating the XML myself in version 1.0.

This is a joy! Thank you!

The library looks quite impressive visually, and seems easy for the JSP developer to implement pretty complex stuff in a few lines.

Like others, not having a server-side piece to complete the puzzle makes it a bit more work to use. I've been using Direct Web Remoting (DWR) for my AJAX needs and am very happy with it. However, the limitation of DWR is that it doesn't have any "standard" JSP tags at all, so you end up doing that part yourself.

I wonder if integrating the two projects would be too much work? That investigation might make for a fun weekend project... anyone have any ideas or want to lend a hand?

I've been working on a XML-RPC module for SpringModules which exposes POJOs as XML-RPC services. We could use JavaScript O Lait to implement AJAX in a relatively easy way. By the way, I don't know if this would have good performance, it is just an idea though.
Darren, probably we can get together and discuss implementing this using AjaxTags.

Cheers,
Alex

I started using AjaxTags since the first beta. I'm very impressed (and pleased) by the easy of use of the tags and the visual quality of the generated DHTML.

Cheers,
Alex.

I just use AJAX on a project, but it would've save me a few hours if this was posted a few days earlier.

How does it work with Struts? Any examples, limitations, drawbacks?


Vipul

How about a BaseAjaxAction, similar to the BaseAjaxServlet?

This is a very helpful tag library. But there is a problem I think. For ajax:select it assumes that I will enter in one text box and populate another with a drop down list. So far so good. But to take the demo example what if after selecting Year i get makes and then depending on the make selection i get models. I do this one Ajax call and get all the data in one shot and then just parse the XML. This kind of use case should be accomodated. Perhaps by exposing the returned XML as a scripting var we can go back to it and reparse it with a post function. I would like to replace my custom stuff with thsi tag if thsi can be done.

I'm glad you brought up this point. It is possible to chain together multiple select fields to accomplish what you want. While it will perform two separate Ajax calls (once for each selection event), the setup is really easy. There's an example of this advanced feature in the documentation: http://ajaxtags.sourceforge.net/advanced.html

Check it out and let me know what you think.

Darren Spurgeon
AJAX JSP Tag Library Team

Do the same without XML:
http://www.servletsuite.com/tips/lists.htm

Tag library for a datagrid (Master / Detail) would really enhance the use of Ajax. Is there any initiative on that.

Wow! I appreciate all the feedback so far--that's what I was hoping for! I've got a lot of ideas in the works for additional tags and improvements, but thought I'd keep it simple for 1.0 and see how it goes from there.

Anyway, I'd just like to respond to a couple points so far.

XML Generation and Communication

Some valid points have been brought up concerning how the XML is both generated and communicated between the server (Servlet) and client (JavaScript) sides. Alex mentioned XML-RPC; Peter mentioned DWR; others have touched on this, too. Right now, the JavaScript (JS) expects XML in a certain format, although the element names are unimportant--the JS simply looks for one root element and children of that node.

I do agree with you all that we can take it a step further. It should be easy to abstract that XML on the server side enough so your code doesn't have to worry about formatting the response. We've shown a little of this with the example application where we extend our servlets from an abstract class that handles the general response. XML-RPC or other "standard" is one possiblity for abstracting this further. Whatever it ends up being, I'd like to keep it simple.

Struts and Spring-MVC Usage

In writing the example application, we toyed with Struts and Spring-MVC examples, too, but thought the exercise was trivial and easily ported from our generic servlet implementation.

DHTML/CSS

I've heard good feedback on the look and feel of the example app. In all honesty, I have to say it's pretty simple really and largely up to each developer to extend or modify. My CSS skills are limited, but I'm going to be enhancing this to (1) provide more flexibility and (2) distribute an example stylesheet that would probably suit most cases without modification.

Upcoming Features

Here are some things on the TODO list:

New tags: tree/navigation, tab menu, progress bar, content refresh (on timer)
Enhancements: multiple servlet request parameters; multiple toggle tag states
Code additions: some way of abstracting XML communication
Base/sample actions for Spring and Struts

Thank you all for the feedback (and don't stop now)! Hopefully, upcoming releases will incorporate many of the ideas I've gotten so far. Of course, being open source, help is always appreciated!

Darren Spurgeon
AJAX JSP Tag Library Team

It is worth noting that there was an AjaxTags released in May that was Struts-specific (http://struts.sourceforge.net). That taglib has now been made generic (does NOT require Struts) and is a component of the Java Web Parts project (http://javawebparts.sourceforge.net). Although the focus of that AjaxTags and this AjaxTags is a bit different, hopefully there won't be confusion because of the common name.

It's a pity that you have to use Javascript for Rich Internet Applications and cannot use Java applets. With applets you could do your server-side and client-side programming in the same proven Java language and even could share some code.

Unfortunately there is no way to access the HTML DOM from a Java applet directly, it is only possible to communicate to JavaScript (http://java.sun.com/products/plugin/1.3/docs/jsobject.html).

So, for an applet based Ajax the Java plugin would have to be enhanced with an API to access the HTML DOM.

What do you think about this idea?

Well, I think that would be not unlike when you use a 200$ powerdrill to hammer in a nail. If you fire up something as powerful as applets, then you could (should?) do the whole AJAX part in the applet (RIA).

As an example: as most companies we have an hour registration webapplication, which requires some AJAX alike functionality on the entry page; opening the project tree is better when doing loading-on-demand, when adding something to the list of hours you want the project name to be fetched, etc.
In regular HTML this was cumbersome and involved multiple pages, resubmitting and javascript. We replaced all the entry pages it with one applet which talks Hessian to the back end (so it still is a solid webapp). A little time was invested to make the applet look good with some gradients and animations.

I want to say thank you again for all the interest we've received since launching the initial release. I don't know whether it's adrenaline or simply the outpouring of encouragement and suggestions, but I've since been motivated to work hard to fix some of the small bugs found over the last two days.

With that comes release 1.0.1, fast on the heels of the initial 1.0 announcement. You can find it over on the SourceForge project page. This release contains mainly bug fixes, as I said, but also has sample CSS and images included with the main distribution instead of just with the example app. Oh, and release notes are now included. How could I have forgotten that in 1.0!?

I expect to release another quick hit (1.0.2?) in the next week or two which may include some DHTML/CSS adjustments based on feedback. After all, appearances are important and sometimes CSS can be tricky--even for me--but I'll take one for the team and tough that one out so you don't have to. Following that will be a longer release cycle toward 1.1 that will include some new tags we on the team are excited about developing. Hopefully, you will be, too.

Thank you!

Cheers,
Darren Spurgeon
AJAX JSP Tag Library Team