AJAX (Asynchronous JavaScript and XML) is nothing new. The technologies behind AJAX have been around for quite a while. Jesse James Garrett just gave the amalgamation of XML, DOM, and JavaScript a catchy new name. Many CF developers hear buzzwords like AJAX and Web 2.0 and simply tune out because they think it's too much to comprehend.

If they'd simply stop and take a look at what AJAX can deliver, they'd see that it offers a unique opportunity to deliver a user experience that seemed beyond reach only a short time ago. With AJAX, a developer can deliver an application that requires only a fraction of the page refreshes of the typical Web application, thereby significantly enhancing the user experience. Delivering this wonderful new experience, however, is another matter. A developer must make use of the XMLHTTPRequest object, which isn't implemented the same way in all browsers. A developer must also have a pretty good understanding of JavaScript. Not all CF developers are strong JavaScript developers or even have JavaScript experience, save a few. What was needed for CF developers was a lightweight, easy-to-use way to leverage the power of AJAX. A number of frameworks for AJAX are available, but none of them are terribly easy to learn and get started with right away. There was no simple solution for AJAX that CF developers could embrace as a community.

This is where Spry comes in. Early in 2006, Adobe started releasing pre-release previews of Spry. Spry is an AJAX framework, a simplified way to make the power of AJAX available to the masses. There are three main components to Spry: XML Datasets, Widgets, and Effects. XML Datasets are, as the name implies, datasets based on an XML document. Widgets are a combination of JavaScript, HTML, and CSS that provide some form of advanced functionality in a self-contained block of code. Effects are simply that, effects that can be applied to HTML elements in a page. Spry also leverages the Google XPath library to facilitate parsing the retrieved XML document into easily accessible datasets. Currently, Spry is still in pre-release status. Adobe's intention with Spry is to make AJAX easy and accessible for Web designers who have little or no JavaScript experience. It will be an integral part of the next release of Dreamweaver. Something that Adobe didn't count on was that one of its existing user communities would latch on to this framework so quickly: the ColdFusion community.

The link between ColdFusion and Spry is almost natural. ColdFusion gives developers the ability to generate XML on the fly, which can then be fed to Spry. Some RDBMSes, such as Microsoft SQL Server (2000+) and Oracle, can even return query results as XML. All that's needed from ColdFusion is some simple formatting and a mechanism to pass the XML to the browser. XML doesn't have to be generated by the database itself though; functionality to convert any data type into XML can be written in ColdFusion by the developer. See Listing 1.

It's important to note that when creating XML to return to Spry with ColdFusion, it's not necessary to return a ColdFusion XML object. In fact, Spry won't understand what's returned if the XML object is returned because ColdFusion will serialize it into a WDDX packet. XML must be returned to Spry in its text format, as an XML document, not its ColdFusion XML object format. Using the ColdFusion XML object when generating the XML document can actually create more overhead in a high-load application because it takes up more space in memory than a simple string would in memory. Best practices for generating XML to be delivered to the browser or AJAX shouldn't involve the use of the ColdFusion XML object.

To return the XML document to the client, ColdFusion needs to set the proper MIME type. If the proper MIME type isn't set, the server will tell the client to expect HTML and not XML. To return the XML document to the client, the process is as simple as using CFCONTENT and outputting the variable. (See Listing 2.) This will ensure that the client expects XML to come back from the server, not HTML. This is key when dealing with Spry because not returning XML will throw an error when loading the XML dataset.

Spry doesn't care if its data comes from a flat XML file, ColdFusion, PHP, or wherever. All it cares about is the MIME type being "text/xml." The syntax for using Spry doesn't change with dynamic XML coming from ColdFusion. This is the beauty, and commonality, of Spry. If the XML is a static document, or a dynamic document, Spry will read it. All Spry cares about is the XML being well formed and the XPath being valid. This opens Spry up to the Web development community at large, not just the ColdFusion community.

Now that this new functionality is available to ColdFusion developers, where does it fit into the user experience? A common problem that Spry solves quite easily is the creation of dynamic dropdown boxes that don't cause the page to be refreshed entirely. This lack of a visible round-trip to the server is beneficial because it enhances the user experience and makes a Web application behave more like a traditional desktop application. Does this new ability to create rich user interfaces for Web applications mean that Spry should be implemented heavily throughout ColdFusion applications? The answer is a resounding "no." If using ColdFusion to generate XML for Spry, remember that each time a request for XML is made, a ColdFusion thread is being used. High-load applications can suffer performance problems in such an environment if the load gets to be too great.

Spry is a perfect fit for teams that are already in a page-based pure HTML environment. For teams that already have a MVC framework in place, Spry offers a nice enhancement to the view layer of the model without compromising the existing framework. If the goal of a development team is to move into more advanced user interfaces then Spry may not be the best fit. An environment such as that may want to look to Flex 2, especially if the development team needs to visualize and manipulate data in a non-HTML manner. Each project and team will have different requirements. Some situations will call for Flex, whereas some situations will call for Spry. It's simply a matter of choosing the proper solution for the problem at hand. (Table 1)

Spry is giving developers a way to change the way interfaces are built within the current limitations of the browser. This opens new doors for developers who are not looking towards Flex 2, but want some of the same type of functionality in their applications. Combine this powerful AJAX framework with the power of ColdFusion and the possibilities are endless. Spry was really meant for the designers on the Web, but ColdFusion users are the ones who will take it beyond its boundaries and into an even richer experience than was originally intended.SIDEBAR In addition to simply displaying the XML data, Spry offers functionality for sorting, filtering, and dynamically reloading datasets. This allows a richer user experience than simply displaying data. Datasets now become interactive and bring a richness to the browser that was previously non-existent. Adobe is continually adding more functionality to Spry with every pre-release. As Spry moves closer to full release, expect to see nested datasets and support for JSON (JavaScript Object Notation) datasets as well.