While Ajax applications often aim for a desktop application-like feel, most organizations will extend existing Web apps with Ajax features, instead of creating Ajax applications from scratch. Thus, as Brian Walsh argues in his TheServerSide.com article, Ajax and the Spring Framework with TIBCO General Interface, many Ajax projects will follow a rapid development style, modifying existing server-side code to work with Ajax, and minimizing new client-side code.

In the article, he shows that the Spring framework and TIBCO's General Interface (GI) toolkit fit these requirements well: An existing Spring application can be modified to emit XML instead of HTML, and TIBCO's GI toolkit can produce most of the JavaScript the client requires.

Walsh starts out converting an existing Web app by re-configuring Spring to produce XML:

Any Ajax implementation makes certain demands of the server. A key pre-requisite is a structured message. GI, like most Ajax libraries, is highly optimized around this concept (though GI also provides a less optimal means to consume and display server generated chunks of HTML as well). Therefore we need Spring to produce a simple, consistent XML payload.

Spring makes our life easy in this regard. Spring can chain view resolvers, passing the requested view to a series of resolvers until it one responds with a view that can render the model. Our first change will be to add a XMLViewResolver. The XMLViewResolver is a Spring provided class that reads a configuration file of view names that we want rendered into XML.

Having configured Spring to produce XML output, he modifies an existing controller layer to be able to deal with the new XML payload. The article then discusses the changes on the client:

The output of GI Builder [TIBCO's browser-based developer environment] is mostly XML models of GUI definitions and client-server communication processes. These models, served as .xml files from any HTTP server, are interpreted at runtime by the GI Framework so as to generate instances of GI JavaScript class objects on the client. Thus the developer's job is mainly concentrated on visually assembling GUI components then linking and orchestrating the services. One does get into JavaScript programming using the JavaScript APIs to the GI class objects for purposes of implementing client-side behaviors and interaction logic. Value adds on the client include parsing the Spring exception message and marshalling form attributes.

Walsh describes how to specify internationalized messages to the UI, and then focuses on GI's ability to handle incoming XML messages:

Next step in construction is to handle the messages created by the XMLView to and from the server. GI provides a high level service (jsx3.net.Service) for you to extend. The GI Service has several responsibilities:

• Marshalling UI screen component content to a request message
• Sending that request to the server
• Un-marshalling the response message to UI components
• Calling user provided event handlers (success, error, timeout)

The Service interprets a set of message transformation and object binding rules stored in a rules/*.rule file. These rule files are created with the XML Mapping Utility, a rule editor within GI Builder. Rules files enable message formats, urls, data, and UI mappings to change independently of the JavaScript controller that orchestrates them.

Walsh's article provides an interesting illustration of how several Web pages can neatly be combined into a single tabbed-pane Ajax component, providing better usability.

To what extent do you think it's worth adding such UI features to an existing Web application? And how would you measure the pay-off for such work?