TapeTrader.com is a ColdFusion-powered, live music sharing community with over 50,000 members and a vast database cataloging hundreds of thousands of hours of live music recordings. The TapeTrader.com community connects fans together so that they can catalog, share and trade their recordings.

In addition to my day job at StubHub and my personal project running (ColdFusion powered) GuitarsAndMore.com, I contribute some engineering time to the TapeTrader.com community. You get the idea... I'm a live music fan!...and kind of a nerd.

When TapeTrader.com wanted to update its live recording catalog user interface, we turned to AJAX and TIBCO's General Interface software to provide a feature rich GUI that looks and feels more like a desktop application than a standard Web application. Using the General Interface AJAX libraries and visual AJAX tools, which TIBCO Software recently provided for free, made the job quick, painless and fun.

This article discusses how we transformed our existing CFML/HTML pages into XML services optimized to work with the TIBCO General Interface (GI) AJAX libraries.

Before and After
The old HTML pages generated with CFML were good, but not great. Some members have huge show lists and paging through the results could be tedious, not to mention the extra load put on the database and Web servers (and don't get me started about maintenance).

It was decided, instead, to create a system that could transfer the entire result set to the browser using XML, which made the process of exploring a catalog of recordings a client-side process. By running the Catalog Explorer application on the client, we can deliver a much richer and friendlier user experience. As shown in Figures 1 and 2, this application provides the ability to explore a member's list, add selections to your "favorites," and see a recording's details, all within a single screen. The legacy HTML application required many separate pages/pop-ups and cumbersome server calls to facilitate that same interaction.

Architectural Choices
Running the JavaScript application in the browser prevents the need for page refreshes for each interaction. It also allows us to send query result sets from the database to the browser in a single request as opposed to the constant querying and subset pagination that is required with the standard HTML page interface (see Figure 3). This not only reduces the number of hits to the server, but also improves the user experience by eliminating the latency of HTTP requests and server-side processing time.

The General Interface libraries map well with these concepts. They provide the rich user interface controls we need, as well as an "XML data cache" object and easy-to-use data-binding mechanisms to bind our XML to our GUI (see Figure 4). It was relatively easy to modify our current CFML routines that were previously used to process, generate, and send XML files to be consumed by the client-side GI user interface. Because these new ColdFusion scripts are pure data services, the XML feeds can be used in other applications or given to users to implement as they wish.

Creating Our AJAX Rich Internet Application
GI's visual development environment (GI Builder) makes it fast and easy to create a feature-rich user interface. GI Builder provides many out-of-the-box GUI components that you simply drag and drop together to create any user interface you like. Styles are set using the component properties or by using CSS. GI Builder's event editor makes it simple to bind JavaScript functions to user interface components, and the JavaScript editor provides menu-based references to the more than 100 Java Script class objects that make up the underlying GI Framework. Asynchronous communication classes, data-caching objects and many other goodies are packed right into the GI Builder environment. GI Builder provides wizards for connecting to XML, SOAP, JSON and CSV data services, as well as nifty debugging and logging capabilities which are very useful when creating JavaScript applications. If necessary, GI Builder can connect to JSON and other HTTP service types via GI APIs. You can find a lot of great documentation, tutorials and chat boards at the TIBCO Website (www.tibco.com/devnet/index.html).

The source code for the GI project demonstrated in this article can be downloaded from the online version of this article at http://coldfusion.sys-con.com. You can view the source files with any editor, but it is best to use GI's visual editor as GI Builder is optimized for GUI file types. You can download GI Builder for free at www.tibco.com/devnet/index.html.

Let's start by creating our ColdFusion data services, and then we'll create the UI and bind it to the GI AJAX application.

Server-Side Code
Listing 1 shows the original ColdFusion code which generated the HTML for the Catalog Explorer. A couple of queries are executed against the database, the results are looped through with some conditional logic, and HTML is generated and sent to the browser. Pretty standard ColdFusion stuff.

Recall that in GI applications, HTML is not needed. The UI is generated by the client-side GI framework in the browser. To create our new application, we can strip the code in Listing 1 down to its very basic elements that provide the needed data as a simple data service. To do this, we need to define how the XML response from the server should be structured such that the client-side GI app can consume it.

GI's Common Data Format (CDF)
While GI can work with any XML, SOAP, JSON or CSV source, its GUI components are set up to bind to what it calls Common Data Format (CDF). CDF is a simple XML schema for describing data where each unit of data is bounded by a <record> node. <record> nodes can contain other <record> nodes to describe hierarchical relationships. The <record> node is used as a pre-set delimiter to which GI's GUI objects can automatically bind. The <record> node thing is handy, but one has to wonder a bit why any XML wouldn't work if you could just specify <artist> as a delimiter and iterate on <artist>... but anyway, that's how GI works.

Luckily, if you do happen to have a data source that comes from a service that's not in the CDF format, GI Builder provides both visual tools and APIs that let you transform these XML structures into and from GI's CDF format. This allows you to preserve the semantics of the original XML while allowing GI's CDF to simplify client-side development. Tip: For large data sets, be sure to use the .compile() method for XML to XML transformations. This will use a faster XSLT processor that is much more efficient than JavaScript.

For simplicity, our application uses ColdFusion to generate the data feed in the CDF format. Listing 2 shows what we need our CFML to generate for client-side consumption.

Listing 3 shows the CFML service used to generate the CDF data feed. Note that we reused the query from the original source code, but added the extra detail needed for this data feed. We are getting nearly all the data we need in a single query operation, then generating a hierarchical GI's CDF data feed as output instead of generating HTML. This method of development allows the ColdFusion code to be much simpler and cleaner, and since we're not sending HTML requests back and forth, we significantly decrease bandwidth, server and database utilization. Once the data is sent to the client, the trader has all the data necessary to browse the entire collection of another trader.

Note the inclusion of the prepareGiOutput() function, which adds an XML header tag, and the root <data> node required by GI's CDF schema, and removes extra, unnecessary white space (speed is everything, after all).

Connecting the Client Application to the Data Service
Listing 4 shows the JavaScript code that is part of the client application. This code uses GI's jsx3.net.Request class to asynchronously call the ColdFusion XML service we created earlier as a GET operation. Any input the service needs (in this case, trader_id) should be passed as URL variables. Upon receiving the response XML from the service, the data is put into cache and the data grid component updates its view (a pattern consistent with the standard Model-View-Controller architectures). GI's data grid class is called a Matrix. The Matrix control can render as a grid, a list, or a tree with a variety of cell edit mask types. jsx3.gui.Matrix also implements the jsx3.xml.CDF interfaces and can contain columns of the type jsx3.gui.Matrix.Column. Like all GI GUI components, the Matrix component in GI Builder is configured through the properties editor or through JavaScript APIs. Tables 1 and 2 show the core properties needed to establish the binding between the Matrix data grid component and the CDF data in the cache.

Other Matrix and Matrix Column properties enable you to configure the sub-categorization of data, tune the pagination and expand/collapse display of data, and stylize the look and feel of the control (see Figure 5).

A Note about Security
Security seems to be one of the development community's concerns these days regarding AJAX. One of the nice things about the approach outlined earlier is that, from a security point of view, it all works within the existing Browser/Server security infrastructure with which, from the last decade of Web application development, we're all familiar. We could authenticate and control access to the .cfm processes that return XML the same way we would for any other HTML page. Further, by using XML as opposed to JSON, the client-side application is less subject to code-insertion risks since the data stream never needs to be evaluated on the client. Since XML is also piped through the XHR object in the browser by GI, it benefits from the XHR's restriction to talk to data services only from the same server as the containing page.

This restricts cross-site scripting and (unless you want cross-site scripting) is a good thing. For solutions like mashups, when using the XHR or GI, usually one will set up a gateway to the remote data domain in the form of a server proxy. This server proxy also gives an added place to implement security policies, and to log and monitor traffic between your primary security context and other security contexts. Most security concerns popping up today are from people making the same kinds of mistakes that we made seven or eight years ago in relation to CGI processes and the like. But this topic could be the subject of another paper, so let's just stop here for now.

Conclusion
AJAX not only enables a richer end-user experience, it also promotes the creation of data services that can be reused by multiple applications. This article explored how the AJAX Rich Internet Application toolkit TIBCO General Interface can be used to rapidly create rich interactive GUIs that could be used in conjunction with CFML pages that output XML rather than HTML.

Resources