We're not limited to storing HTML code in a variable defined by the <CFSAVECONTENT> tag. We can also specify JavaScript and/or Cascading Style Sheet (CSS) syntax in variables defined by <CFSAVECONTENT>. Better yet, we can use CFML to create dynamic content in HTML files that are written to the server with <CFFILE>. Taking our simple example a step further, let's add some CFML to the <CFSAVECONTENT> tag in Listing 1 to display the current date in our output file. This is shown in Listing 2.

Notice how we're able to use both HTML and CFML between the opening and closing <CFSAVECONTENT> tags in Listing 2. ColdFusion will evaluate the CFML between the opening and closing <CFOUTPUT> tags and then treat the resulting code as one long text string. It then assigns this string to the "myHtmlCode" variable. It's like we're "injecting" the HTML and CFML that's needed to create our file into the <CFFILE> tag's "output" attribute. When the <CFFILE> tag executes it will, once again, use the source code that's stored in the "myHtmlCode" variable to create the HTML file and write it to disk. When loaded in a browser this page will display the message "Hello World, the date is [today's date]!" The <CFSAVECONTENT> tag lets us use CFML and achieve precise control over the code that's written to our output file.

There is another important aspect of <CFFILE> that you should know about. When <CFFILE> is instructed to write a file that already exists to the server, the original file is overwritten and replaced with the new one. So be careful when using <CFFILE> because you can overwrite important files on your server. I always make a special directory on the server to hold my ColdFusion-generated files and confine my file writing activities to that directory. That way I can be reasonably sure that nothing really important is being overwritten on the ColdFusion server.

Of course, it's also possible to retrieve data from a database and put it in the <CFSAVECONTENT> tag to include in a file that's subsequently written to the server with <CFFILE>. Conceptually, this isn't much different from the example in Listing 2 since we'd just be substituting query results for the current date and writing a single output file to the server. However, getting back to the task at hand, what if we wanted to generate a hundred or even a thousand static Web pages from information in a database and mimic the functionality of a dynamic data drill-down application using only static Web pages? By now it should come as no surprise that even these tasks aren't too difficult. After all, this is ColdFusion we're using here! The code in Listing 3 does this seemingly impossible task by putting the <CFSAVECONTENT> and <CFFILE> tags in a <CFLOOP> tag.

There's a lot of code in Listing 3, so let's get right into it. The code loops over the "listAllRecords" query executing the <CFSAVECONTENT> and <CFFILE> tags once for each row retrieved by the "listAllRecords" query. With each pass through the loop, the CFML inside the opening and closing <CFOUTPUT> tags is evaluated and the resulting HTML source code that comprises that HTML file is assigned to the "myHtmlCode" variable as a text string. In this case we're outputting, within each HTML file, the Project ID, Name, Description, and Last Modified date values for each record retrieved by the "listAllRecords" query. The myHtmlCode variable, which holds the HTML source code for each file, becomes the value of the "output" attribute in the <CFFILE> tag and the resulting HTML file is written to the "files" directory on the server. Thanks to the <CFLOOP> tag, this process is repeated for every record retrieved by the "listAllRecords" query. Each static Web page written to the server is unique because it's populated with the data from a single row in the database. Notice the code in the "file" attribute in the <CFFILE> tag. This code defines the full path (on the server) and filename of the HTML files that are written to disk. It's dynamic and will change with each pass through the loop. This means that the files (i.e., Web pages) that are written to the "files" directory will be assigned sequential filenames comprised of a "p" concatenated with the "projectid" value and will have an ".html" extension. This will produce filenames such as "p1.html," "p2.html," "p3.html," etc. for the files written to the server. In other words, the filenames are sequential and correspond to the "projectid" values in the database.

Now I'm a Believer
I must admit the first time I ran the code in Listing 3 in a Web browser I was doubtful it would work. I fully expected it to crash and give me a dozen error messages pointing out the flaws in my code and describing why it was impossible to do what I'd asked it to do. Imagine my surprise when the template, which I'd aptly named "pageGenerator.cfm," executed on the first attempt without any errors and sat there waiting for me. At first I thought that it hadn't done anything much less written hundreds of HTML files to the server, because it executed so fast. But when I checked the "files" directory on the server -which served as the repository for all of my ColdFusion-generated files - I found more than 700 HTML files there! (See Figure 1.) Moreover, each file had a unique sequential filename (based on the "projectid" parameter), syntactically correct HTML source code, and unique content derived from the "myProjects" database. So, the bottom line is that ColdFusion enabled me to create, in a matter of seconds, hundreds of static Web pages populated with data from a database. If that's not working efficiently and making the best use of my time, then I don't know what is.

Remember the basic data drill-down application I mentioned earlier? It would now be possible to mimic this functionality - using static pages - by creating a "master" static Web page containing links to each of the "details" pages I'd just created. The master static Web page, which is created with ColdFusion (of course), lists three database column values: Project ID, Project Name, and Last Modified Date. The "Project ID" values serve as links to the corresponding "details" pages. These links are created by concatenating a "p" with the "projectid" value as shown in Listing 4.

When this code is run, a static Web page named "masterpage.html" is created and written to the "files" directory on the server. This page displays the Project ID, Project Name, and Last Modified Date for every record retrieved by the "listAllRecords" query. The Project ID column values are linked to the corresponding "details" pages. Remember how the filenames of the 700-odd "details" pages were derived from the Project ID values? It's the same thing here only this time we're creating a single Web page with links to each of the 700+ "details" pages. There's a direct correlation between the links in the "master" page and the filenames of the details pages, i.e., they are both created from the "projectid" values. So the details of any record can be viewed by clicking on the appropriate "Project ID" link in the master page, as shown in Figure 2. Using just two ColdFusion MX 7 templates (Listings 3 and 4) and a database, we can automatically create a large static Web site - with basic data drill-down functionality - in a matter of seconds. As a final touch and to aid navigation within the static site, a simple HTML link back to the master page can be put on each details page.

There are some significant benefits to using <CFFILE> to create static Web pages using ColdFusion. First, it doesn't matter how many database records there are. Granted, it will take ColdFusion a little longer to process 700 database records (and write the corresponding HTML files) than it will to process just a few, but ColdFusion and the database are still doing all of the work, not me. Plus it's getting done much faster than I could ever do it. Second, by modifying the query parameters it's easy to control what static files are actually generated and written to disk. For example, I could have easily used a WHERE clause in the "listAllRecords" query in Listing 3 to limit the query results to only those records that meet certain criteria. Then only Web pages representing the retrieved records would have actually been generated and written to the server. In fact, this is an excellent way to update and maintain a pseudo-dynamic Web site. For example, assuming your database has a "Last Modified Date" column (indicating the date/time each record was last updated), you can easily limit the query with a WHERE clause to only those records that were modified during the past day, week, month, etc. Then, the only static pages that would be generated by <CFFILE> (and written to the server) would be those that contain data that was modified in the past day, week, or month. You could then overwrite the old outdated static Web pages with the new ones on your server, and your pseudo-dynamic site would be updated with only a minimal effort on your part. Of course, you'll have to upload (FTP) any changed files to the server manually but you'd need to do that anyway with a static Web site.