Flash Forms

Digg This!

Dashboards are user interfaces that organize and present information intuitively, usually with graphical elements. The information is often aggregated from several sources (databases, operational metrics, log files, etc.) and summarized. They are often used by decision or policy makers.

Using CFMX v7's <cfform...> tag, you can build Flash-based forms whose "controls" look much like those found on standard "fat clients"; you can also build charts and graphs. However, combining them in a typical dashboard application results in a rather hodgepodge look-and-feel. Of course, you can hand-code Flash reports and create dial-like controls and eye-catching animations if you have the necessary expertise and time, but if you lack either, you might want to take a look at Crystal Xcelsius (CX). This article briefly describes the product and shows how to deploy very slick-looking, interactive, Flash-driven dashboards using CFMX-delivered dynamic data. It assumes you've installed the CX development software, the IDE.

As it's common practice to import corporate data into spreadsheets for presentation and decision-making purposes, CX's functionality is based upon Excel. Therefore, to build a CX dashboard you must create a spreadsheet containing the data tables (defined rows and columns) and cells that will ultimately be transformed into graphical "eye candy." After performing this step and saving the spreadsheet, the CX IDE is opened, a new project created, and the spreadsheet imported into the project; the latter can be thought of as embedded data structures. You now have the data; the next step is to construct charts, dials, sliders, and other components. Wizards then help you map the data to the component(s). The last step within the CX IDE compiles the dashboard into a Flash file (with suffix .swf), which can be sent to users via e-mail or deployed to a Web server for browser viewing.

Let's look at an example.

Figure 1 shows one tab of a dashboard containing six Flash components. Starting from the top right and viewing clockwise, notice:

1. The multi-colored chart showing the output from each of several different service groups for each month of 2005
2. A button titled "Chart Selected Year" (a specific instance of a component called an "XML Data Button")
3. A combo box for choosing a year
4. A list box for choosing the type of output to be shown (in this case, either the number of contracts or the total $ contract amount for each service group)
5. A dial showing "Contracting Workload"
6. An alert showing the workload trend

The data shown on this, or any dashboard for that matter, can be static or it can be dynamic. If static, it means the data resides in the spreadsheet embedded within the compiled Flash file. If dynamic, it means the data would be retrieved from, say, a back-end database. This is made possible by the XML Data Button component, which sends data from the Flash executable to a back-end CF application, receives the response, repopulates the embedded spreadsheet's tables and cells, and refreshes the visual components. This essentially gives you Flash remoting without a lot of hassle.

In our example, the input combo box is configured to show a range of years that is mapped to a column of spreadsheet cells containing those year-values; its output (the year chosen by the user) is mapped to one of those spreadsheet cells. When the user hits the "Chart Selected Year" button, the value in that one cell is wrapped into an XML packet and sent to a ColdFusion action template that has been designated by a URL in the wizard. At the CF server, the XML packet is parsed and the value (the year in this case) is passed into a database query; data from a static file could, of course, be returned as well. The CF server then wraps the query resultset into an XML packet for return to the Flash file and subsequent display (see Listing 1).

The XC IDE generates the entire structure of the XML packet for sending to and receiving from the CF server, thus simplifying the job of parsing the XML in code. Figure 1 shows four sections of CF code handling these back-end tasks.

Section 1: The data passed in from the .swf is converted (by the CF server) into a struct with an extraneous name=value pair ("FIELDNAMES"), which is removed in this section. What remains is the #form# variable with only the original XML packet created by the .swf file.

Section 2: To prevent the XML parser from throwing an error, the entire #form# variable is changed to lower case. Next, an XML tree object is created and the data (in this case, the year) is extracted.

Section 3: The database is queried by a stored procedure call with the year passed in as the input parameter.

Section 4: The returned cfquery is converted into an XML string for delivery back to the Flash file.

Workflow
We've developed enough dashboards to recognize that it's an iterative process, usually involving an XC "power user," a business expert who knows what data should be displayed, an IS analyst who knows the backend database, and a CF developer.

Summary
The product can be seen as complementary to and as an extension of existing CFMX functionality. The Xcelsius/Flash deployables can, of course, do more than dashboards. Indeed, there are an impressive number of configurable components available within the XC IDE (see the XC Web site: www.xcelsius.com/Products/XL_products.html). The vendor also has a component that purports to offer dynamic messaging between the Flash executable and Web services; however, we couldn't get it to work and, given that the equivalent XML data button serves our intranet purposes well, we didn't try to solve that problem. The documentation, unfortunately, is replete with .asp code and examples but not .cfm code.