I must say that using a datagrid greatly simplified and facilitated my development efforts. First, the datagrid made it possible to display both a "master" list of records and a "record details" section on the same page. When the user selects an item in the datagrid, the details of the selected record appear in the various Flash Form controls on the page. This eliminates the need for separate "master" and "details" templates in the application. The second benefit of using a datagrid is that the amount of code that I had to write was substantially reduced. Numerous HTML and CFML tags were replaced with just three tags: <CFGRID>, <CFGRIDCOLUMN>, and <CFINPUT>. All right, it's really four tags if you count the <CFTEXTAREA> tag. Another benefit of using a datagrid is fewer calls to the database and better performance since the master-detail interface in the Flash Form uses the query data stored in the datagrid, not the database, to populate the form controls.

I soon realized, however, that I had another problem. The "Title" and "Summary" text areas contained large amounts of text and consumed too much vertical space in the form. This made the page too big to see without vertical scrolling. Once again it was Flash Forms to the rescue, this time via the Tab Navigator layout container. The code in Listing 3 shows how I used a Tab Navigator container to distribute the text areas (and other content) among three distinct "tabbed" sections in the form. The content in any of these tabs could be accessed simply by selecting the appropriate tab.

Now, with the Tab Navigator container dividing the content evenly among three tabbed sections in the form, there was plenty of room for all of the form controls, including the two large text areas.

Once I had figured out how to bind the text areas and text input controls to the datagrid, the remaining development work went quickly. I had to consult the Real Estate Sample Application article once more to figure out how to bind checkboxes to the datagrid, but that wasn't too difficult. By now the application was almost ready and I began testing it to ensure cross-browser compatibility. One of the greatest benefits of Flash is its ability to render consistently across a variety of different platforms and browsers. This alone is sufficient reason to consider using Flash Forms for your next ColdFusion project.

Next, I added two <CFSELECT> list menus above the datagrid to let users filter records in the datagrid. The first of these menus filters salient issues according to their confidential status, e.g., Enforcement Confidential, Business Confidential, etc. The other menu allows selection of salient issues that are one, two, three or four weeks old for display in the datagrid. By setting up the page so that the Flash Form submits to itself, I was able to keep it all to a single page. However, in the interest of giving users a "print version" option, I created two "print version" templates that use several URL variables (passed from the main page) to display detailed information on any salient issue in FlashPaper, Acrobat, or HTML format. In the third tab of the tabbed section in the main page (see Listing 3) I employed three <CFFORMITEM> tags with the Type="html" attribute to create three dynamic HTML links. Thanks to the <CFFORMITEM> "bind" attribute, the URL parameters in these links change according to the record that's selected in the datagrid. These links pass the necessary parameters to the "print version" templates, allowing the latter to query the correct salient issues database and retrieve data on the desired record. The code for this is shown in Listing 4

Any salient issue displayed in the datagrid could now be printed in HTML, Acrobat, or FlashPaper format by clicking on the appropriate link in the third tab of the Tab Navigator.

Figure 1 shows the completed Flash UI for the application. I added some fictitious records so that it would look similar to the actual application. By using a Flash Form to handle the data presentation, I had more time to focus on the database queries and other application logic. Frankly, I was amazed that such a sophisticated interface could be implemented so easily and with so little code. But then I remembered that this was ColdFusion, and we all know how ColdFusion excels at making even the most complex tasks seem trivial. Indeed, that's what I like most about ColdFusion, its unique ability to make quick work of complex programming chores so that developers can get real work done. Now, whenever I start a new ColdFusion project I ask myself, "Will Flash Forms work here?" I strongly encourage you to do the same because Flash Forms can save you precious time, simplify your code, and deliver a compelling user experience.

Beyond Flash Forms: Flex 2
As you may have guessed, over the past few months I've been on a mission to "Flash-enable" my applications, and I didn't want that mission to end with Flash Forms. So I began experimenting with Flex 2. My experience with Flash forms made working with Flex much easier. Flash Forms and Flex are quite similar and have much in common such as the controls (e.g., datagrid), data binding, Actionscript, compiled .SWF file output, etc. Therefore, many of the things I learned while using Flash Forms could be applied to my Flex development. Once again I decided to start slow and tackle a relatively simple project. The project I chose was to convert one of our existing ColdFusion-generated permit pages (www.epa.gov/reg3artd/permitting/petitions2.htm) to a Flex page. I say "ColdFusion-generated" because this page really is generated automatically, on a weekly basis, by our ColdFusion server via the <CFSCHEDULE> tag, but that's a story for another article.

Flex applications can't interact directly with a database as ColdFusion does, so the data for Flex applications must come from data providers, i.e., services that Flex recognizes and can interact with. Data providers include arrays, Web Services, HTTP services and external XML files to name a few. That last option interested me the most. If I could somehow use a separate XML file as the data provider for my Flex page then I could update the application simply by replacing the XML file. Plus, there would be no need to concern myself at all with the presentation code when performing data refreshes. The idea of creating a Flex application with separate data and presentation code was very compelling, and so I fired up Flex Builder determined to create a Flex page that gets its data from a separate XML file.

I had previously studied the tips and resources available in the Adobe Flex 2 Developer Center, and the Flex Builder IDE made it easy to construct my Flex application. Working primarily in Source mode, I added panel, datagrid, form, textinput, and other components and used data binding and Actionscript to bind everything together, similar to what I had done when working with CFML and Flash forms.

After some trial and error writing MXML (Flex's XML-based markup language) and Actionscript code, my Flex application was finished. I have since put it on my division's public Web site at www.epa.gov/reg3artd/permitting/flex/t5permits2.htm. The .SWF file, which is the application's Flash UI, is invoked by an HTML "wrapper" page that will prompt the user to download and install Flash Player 9, if needed. A basic wrapper page is automatically created by Flex Builder when an application is compiled, but I modified it to look like a standard EPA Web page so it would be consistent with the rest of our site. I think that creating a wrapper page is a good idea because some users may not have the latest version of Flash Player installed and Flex applications require Flash Player 9.

I'm happy to report that my Flex page uses a separate local XML file named "permits.xml" (www.epa.gov/reg3artd/permitting/flex/permits.xml) as its data provider. So it's possible for even a Flex novice like me to create Flex applications that use data from an "external" source. I even wrote a special ColdFusion template that queries our internal Title V Operating Permits (Oracle) database and constructs the permits.xml file from the query results. When I want to refresh the Flex application with new data, I simply run this ColdFusion template and replace the old XML file with the new one generated by the template. I think that in the future we'll see a lot of database information being converted into XML since Flex can't interact directly with a database but can easily access and retrieve data "packaged" in XML.

Separating presentation and data code certainly has its advantages, but for me the best thing about Flex is that no ColdFusion or other server-side support is needed for basic standalone Flex applications (like mine). Basic Flex applications can be deployed just like HTML files and will work on a standard (non-ColdFusion) Web server. This is important in my situation because, as I've mentioned before, the cost of ColdFusion support on EPA's public Web server is high. Therefore, my Division's public Web site doesn't have ColdFusion support at this time. However, with Flex I can still present our data via a Flash interface.

I've already begun thinking of ways to enhance my Flex page with images, links, or even charts. But I'm out of space for now and this will have to wait for another article. Thanks for reading and I hope that I've given you some interesting ideas on how to use Flash Forms and Flex to revitalize your own applications.