by Robert Crooks

When you're in the static site world, it is not always easy to know, because you don't know exactly what converting your static site to a Web application is going to buy you, and cost you. There is after all a fairly significant investment to be made in going dynamic. You will need a Web application server, new development tools, and some new skills. If your site is running on an external host, you'll also need to convince your service provider to add the Web application server or find another hosting service that already supports one.

So when will the benefits outweigh the costs? The answer will depend on variables that are specific to your case, but I will try to give you some ideas by relating my own experience in building and maintaining a static Web site, and the factors that induced me to convert it into a ColdFusion application. (The conversion is presently ongoing; I expect to complete it in a couple of months, depending on how much time I find to devote to it.)

The Static Problem and The Dynamic Solution
I have been building and maintaining a static site called The Web Worker's Toolbox for several years. The site presently comprises about 750 pages distributed among about 35 page directories, with many more files and directories devoted to images, style sheets, scripts, and the like. The page directories contain sequentially structured guides to various Web technologies, development tools, and design issues.

I began thinking about converting the site to a Web application almost two years ago, but various obstacles delayed the transition. In general, the motivation was that maintenance of the existing site had become a burden that consumed most of the time that I had to devote to it, meaning that the more interesting work of adding new information or improving the site functionality turned into such an endless backlog that it seemed I would never catch up. Let me drill down into some of the specific maintenance issues and describe how ColdFusion will help me deal with them.

Managing Overall UI Changes

From the beginning, I intended to maintain a common page design across the whole site, both to provide a common user interface everywhere, and also to allow me to make site-wide UI changes through extended search and replace actions.

This proved to be an impossible resolution to carry out. I (of course) use HomeSite templates to build all pages and try to keep the page contents rigorously separate from the HTML code that makes up the page layout. But each time I've added a new section, I would inevitably want to try out some new HTML coding technique, or employ a new design technology such as CSS, or automate some additional information item through JavaScript. I try to be disciplined about retrofitting existing sections with the new layouts, but in my desire and sometimes external pressures to get new sections up, I often fail to do so. To make matters worse, I often give in to the temptation to tweak some aspect of the page layout when I'm adding new pages to a section or updating some items on existing pages.

The upshot is that the page layout code among and even within sections is so full of inconsistencies that my ability to make site-wide changes easily is extremely limited.

With ColdFusion, I can eliminate the need for these extended search and replace changes altogether, because almost all of the "pages" in the site can be generated from a single ColdFusion template and a few component sub-templates. One of the strengths of CFML that HTML still sorely lacks is the ability to include external files in a page template through the <CFinclude> tag. A single template thus can include all of the layout code from a few external templates: page header and footer templates, templates for site and section navigation toolbars, and a template for the main page contents. Some specific information items in these templates -- images, section titles, navigation links, pointers to content files, and so forth -- will be variables whose values are stored in and retrieved from relational database tables. Site-wide changes will mean modifying a handful of templates rather than 700 pages.

Synchronizing Information Across Different Pages
We all know that one of the great strengths of hyperlinking is the ability to recombine information in a variety of configurations from a single set of source files. There are limits to this power, though. Aside from the need to replicate headers, footers, and navigation links, there are places in The Web Worker's Toolbox where I need to replicate some bit of information in different sections rather than forcing users to work through a disruptive series of cross-sectional links. Also, because I know many users prefer to print out sections of the site rather than read them online, I combine all the page contents for each section into one single page for printing purposes.

The first problem can be managed to some extent through HTML frames, but the use of frames is a limited solution that easily leads to navigational confusion for users. The <CFinclude> tag again provides a much cleaner solution less prone to inconveniencing users.

For the second problem, there simply is no HTML solution. The information has to be replicated, and therefore it is difficult to keep the different instances synchronized. The <CFinclude> tag makes the problem go away by using the same source information in both cases.

Providing and Updating HTML Code for Structured Sets of Information
Several sections in my site contain large blocks of structured information, such as tables of HTML tags and attributes or CSS properties (on another kind of site, these might be product catalogues, schedules of events, etc.). Hand-coding HTML tables to contain such information is tedious even with a tool as good as HomeSite, and modifying the user interface for large sets of such information far worse. Either way of changing the design -- modifying tables row by row and cell by cell, or constructing complex search and replace operations using regular expressions -- is a daunting enough task that I always manage to find something more pressing to do.

The obvious solution is to maintain this information in database tables, retrieve it when the page is requested, and generate the HTML coding on the fly from a simple, easily-modified template. This is, of course, the core strength of ColdFusion. With a minimal knowledge of relational database design and SQL, and a few lines of CFML and HTML code, I can generate many pages of structured information that are as simple to modify as they are to create. And I can even use ColdFusion to make an easy-to-use administrative backend for adding to and updating the information in the database.

Processing Information from Users
The Web Worker's Toolbox has never been as interactive as I wanted it to be. There are only two forms on the static site, one for submitting HTML problems and questions, the other for signing onto a mailing list that announces major changes in the site. Pretty simple, but all the present site location allows me to do for backend processing is dump the name/value pairs into an email message. These two forms generated far more email than I anticipated, and each message required sending an acknowledgement and entering the address into a distribution list in my address book -- small but time-consuming tasks. A plan to turn add each help request to a kind of FAQ page was soon abandoned altogether.

ColdFusion can automate all of the tedious work here. I can auto-generate email acknowledgements of form submissions, automatically save mail addresses in a database table and generate a distribution list from it, even work up a form for entry of "What's New" items to have them automatically inserted into the cover page for the site and simultaneously mailed out to the distribution list. In the same way I can automatically log questions and answers, and generate pages from them, with filters for different question categories.

Conclusion
There are many other advantages of Web applications that I could list -- probably as many as the hundreds of ColdFusion tags and functions -- but I hope I've already given static site developers some sense of where the gains lie in going dynamic. When is it time to make the leap? You'll have to decide for yourself, based on the particular challenges your site offers, but I think I can safely say that I waited far too long myself.

If you're maintaining more than a couple of dozen pages, collecting and processing information from users, dealing with large lists of structured and changing information, maintaining distribution lists and mailing out regular announcements...it's time to find how much of this work can be automated, and how much time and effort you can save for more important tasks.

-Robert

Robert Crooks is an Allaire Certified Instructor at Allaire Corp. Please direct comments on this column to talkback@allaire.com.