Welcome!

ColdFusion Authors: Yakov Fain, Maureen O'Gara, Nancy Y. Nee, Tad Anderson, Daniel Kaar

Related Topics: ColdFusion

ColdFusion: Article

ColdFusion & CGI: Transitioning to ColdFusion

ColdFusion & CGI: Transitioning to ColdFusion

There's little disputing the pace at which the Web has evolved over the past several years. Fueled by graphical interfaces to a suite of early text-based protocols, the leap into the Internet marketplace by providers of previously proprietary content systems and the plunge in street prices of personal computers, growth of the Internet - most notably the World Wide Web - continues at a torrid pace. In conjunction with the sheer growth has been the evolution of the Web from a place to browse information to a real infrastructure for the development of sophisticated applications.

Five years ago I spent my time on Web servers installing Perl scripts written to the requirements of the Common Gateway Interface (CGI). Soon after, I began my own journey into the world of Perl programming, first as a UNIX system administrator and later as a Web developer. CGI was easy to understand, easy to set up, easy to implement. Then along came Web servers that ran on something other than UNIX platforms. CGI still worked. It needed a tweak here and there and I now had to keep track of win-cgi and dos-cgi in addition to the stuff I already knew, but at the heart CGI was still pretty easy to work with.

About three years ago the whole Web seemed to come into full bloom. Those were great days for CGI programmers (yes, programmers!). New applications appeared daily; the free software movement created a rich environment for coders to learn from each other's work, and the browsing community started asking for more. More dynamic elements, more access to things elsewhere on the Web and, most of all, access to things like corporate databases. It was about this time I began a personal crusade extolling the virtues of Web applications. They were relatively quick to develop. They were easy to deploy to remote locations. They gave you a single point of maintenance. Slowly, people listened. CGI applications flourished.

There was a problem, though. For all the wonderful things CGI applications could (and still can) do, they really did require programmers to construct them and people rather familiar with the operation of Web servers to set them up. To this day, CGI programs still carry the somewhat deserved reputation of being inefficient because of the way Web servers handle the requests. The landscape was now mature enough for a serious Web development environment. Allaire's release of ColdFusion took the development community by storm. The ability to embed a rich set of programming constructs in a markup language - and further integrate that markup language directly in standard Hypertext Markup Language pages - gained immediate attention.

This integration of programming constructs within a markup language is perhaps the fundamental difference between traditional CGI programming and inline programming from the point of view of the application developer. When we move to an environment like ColdFusion, we must think differently about how to architect an application.

Let's look at a quick sample of each in action doing a very common task. It's almost painfully common to see the date and time displayed on a Web page. I say "painfully," because if you think about it most computer users probably already have the date, the time or both already displayed somewhere on their desktop. I swap routinely between sessions on Solaris (date and time displayed in the CDE toolbar), Windows NT (time displayed in the lower-right corner of the task bar, date viewed with a mouseover) and Mac OS/8 (time next to the Finder icon). Why this duplication of effort has become so common can only be attributed to the ease with which it is done and the ability to show the time at the server instead of the client.

First, the CGI way. This actually requires a combination of tools. Very often a CGI script is called via a server-side include "exec cgi" tag. Here's the script (UNIX style):

#!/usr/bin/perl

($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
localtime(time);
print "The time is $hour:$min:$sec" ;

This is called from the Web page with something like:

<!--#exec cgi=" /cgi-bin/thetime.pl" -->

This produces the result shown in Figure 1.

This method works, though the different configurations for server-side includes may make it something less than completely portable. Experienced CGI programmers will note the absence of a content header. I've run into Web server configurations that require it as well as those that don't.

Now let's put that same thing into our home.cfm page and see what changes.

<CFOUTPUT> The time is #TimeFormat(Now(), "HH:mm:ss" )# </CFOUTPUT>

This results in exactly the same output format as shown in Figure 2.

Two points are significant here. First, the CGI implementation requires that server-side includes be enabled. Second, the CGI implementation uses a separate script, which must be installed, configured and permissioned correctly to work. Even Perl bigots like me can be swayed by the ease of the task with ColdFusion.

This example illustrates a difference in the architecture between CGI-driven applications and those constructed with inline scripting tools. At the very heart of the difference is the separation of program code from display code. Under the "standard" CGI configuration on Web servers, all files intended to be run as scripts must reside in a specific directory tree. Servers are often configured to map this real system directory to the URL "/cgi-bin." The display files are most often separate HTML files that reside in the document tree of the Web server. Scripts must be configured to be executable by the user id under which the Web server runs. The installation and setup of even a simple feedback form will require managing files in two separate directories.

A typical ColdFusion application will place all files in the same directory somewhere in the Web document tree. The "display" and the "processing" may well take place in separate files, but the front end of this is very likely to have dynamic elements such as retrieving information from a database to populate a select menu. To accomplish that process in a CGI application would require the script itself to generate the HTML. I have commonly deployed CGI programs in this manner, but have found them very inflexible. Any changes to the visual interface must be made to the script itself - often by a nonprogrammer whose comfort level reading a programming language leaves a bit to be desired. To further complicate matters, the editing is usually done locally (note that most of my CGI travels have been on UNIX systems) and files are then uploaded. As often as not, uploaded as binary and corrupted. A one-liner in Perl fixes that problem faster than I could probably teach a graphic artist how to get around in VI, so I've at least learned to take that one in stride!

So what about more useful things? In the old days on the Web (you know, way back in about 1995), pretty much everything was accessible to anyone who was browsing. Not so anymore. These days I find myself logging into all kinds of things. And the site is keeping track of me somehow, often in a database.

Databases come in various shapes, sizes and degrees of scalability. From simple flat text files to large-scale data warehousing systems, there are database solutions for storing all types of information. Because ColdFusion is platform-specific, running only on Win32 and Solaris, I'll confine the following example to a readily accessible product, Microsoft Access running on a Win32 system. I typically develop on Windows NT v. 4.0 and find it much easier to move things to UNIX from Windows than vice versa.

To implement a login, several things occur. The user is presented with a login dialog box with inputs for a user name and usually a password. The user clicks a submit button and the form is processed by an authentication script that connects to a database, looks up the user name and, if found, compares the stored password with the input. A successful match gets the user to the desired page. A login failure does something else, hopefully something intuitive enough to the user to determine the next course of action. Simple enough concept, and accessible enough to show the ease of transitioning from traditional CGI to inline scripting.

Figure 3 shows a simple login screen. The form fields are "user" and "pass," which for the sake of clarity we'll assume exist in the database as columns username and password. Listings 1 and 2 contain the complete source to the login screens. I'll parse them into variables whose names match the form elements for the CGI example. We'll query the database with the user input, then examine the password field from the query and compare it with the pass input. For the CGI implementation I'll use Dave Roth's Win32::ODBC.pm module.

The complete source can be found in Listing 3. We'll show just the pieces relevant to the database query here. Note that, for simplicity, the examples are shown without any error-checking routines. This would obviously be poor practice in a production environment!

First connect to the database (using a previously defined System DSN):

$db = new Win32::ODBC("members" );

Then do the query and load it up into a hash:

$db->Sql("select * from logins where user = $user" );
$db->FetchRow();
%matches = $db->DataHash;

At this point, if the query was successful, we should have a single record stored in an associative array (a hash, in contemporary PerlSpeak), which we can work with in the same manner as the parsed form data (see complete code listing). To do my comparison:

if ($pass eq $matches\{'password'\}) \{
print "Location: $url\\n\\n" ;
\} else \{ …. your login failure here …. };

This is a bit simplistic, but the basic steps are:
1. Set up the module for use.
2. Create an instance of it.
3. Query the database.
4. Load the returned data into a data structure.
5. Do comparisons between stored data and user inputs.
6. Direct to appropriate page.

Now let's take a look at an equivalent sequence with ColdFusion. Using a similar front end (Listing 2), I then do the query (Listing 4) as follows:

<CFQUERY NAME=" matches" DATASOURCE=" members" >
select * from logins where user = \lquote #user#'
</CFQUERY>

Again, perform the comparison:

<CFOUTPUT QUERY=" matches" >
<CFIF #password# IS #pass#>
<CFLOCATION URL = "success.html" >
<CFELSE>
<CFLOCATION URL = "failure.html" >
</CFIF>
</CFOUTPUT>

The sheer amount of code required to do the database-specific functions is roughly equivalent. Not apparent is the amount of work required to get to this point. The form must be parsed for the CGI example. ColdFusion handles this internally. The error handling shown in the full code listing requires some handling differences, though these can be minimized by using a global error routine. I often place this error routine in an external file and include it in my CGI script. In ColdFusion a similar approach is to place shared (global) items in the APPLICATION.CFM template.

Project-based tools have become standard fare in the application development world and have made their way into the Web application world as well. Comparing development environments between traditional CGI programming in Perl and ColdFusion is a bit of a lopsided battle. While several products have recently emerged with visually attractive interfaces for programming in Perl, I've yet to find a competent product that is effective for CGI programming. I personally rely on a marvelous programmer's editor called UltraEdit, which has language-specific dictionaries to do basic syntax highlighting and has configurable menus that let me call up Perl's built-in debugger to run syntax checks on scripts in a separate window. From my current menu setup, shown in Figure 4, I can either run a script or simply run the Perl interpreter in syntax check mode. Both produce output in the editor's own results window.

Great product at a great price, but as good as it is, a text editor is hardly a substitute for a full-featured development environment such as the ColdFusion Studio.

Like its little brother HomeSite, the ColdFusion Studio serves the dual function of a project organizer and graphical coding environment. Though I tend not to use the individual tag shortcut buttons, having cut my markup language teeth on VI, things like tag completion, context-sensitive tag help and wizards to set up things like framesets and table are wonderful productivity boosters. The CF Studio's project manager falls well short of a version control product, but does provide a convenient means of keeping files organized (see Figure 5).

Since the standard CF-driven application will often reside in a single directory, a very convenient feature is to open the remote documents, edit them and save them back to the remote site. Additionally, making the same change to a collection of documents is easily accomplished using the extended replace command on the entire project. Somebody was thinking!

Debugging is a somewhat quirky thing in markup languages and, after all, the ColdFusion Markup Language is really just a markup language, albeit one that includes standard constructs for conditional programming structures and access to the Standard Query Language. The CF Studio comes integrated with the CSE HTML Validator. It won't debug your SQL statements, but it can at least help you get accurate renderings of display code.

Another area where the CF Studio shines is the application wizards to help programmers get started on the most common types of pages. One in particular, the Verity wizard, is an absolute gem for getting a simple search function running on a Web page. Wizards exist for HTML, Dynamic HTML and ColdFusion pages. While you're unlikely to use a wizard to build a large application, they make great learning tools.

The feature I find most appealing about the CF Studio is the connectivity to the data sources during development. As databases grow, tables multiply as well as get complex themselves. It can be difficult just to remember field and table names. From within the development environment you can view the tables and the columns within the tables of your data sources. This saves me having to keep a database access tool running or keep a database diagram taped to my monitor.

So what happens after you've developed your application and are ready to put it out onto the Web? I've spent a fair amount of time in a shop whose pet term is to "deploy applications." As a former military officer, the thought of deployment conjures up a set of images quite removed from the Web! Whatever you call it, you do need to get your work off your local hard drive and onto a Web server.

To move a CGI-driven application to a production server, you'll typically create a bunch of directories, upload files to those directories, set permissions on directories and files and hope you've got all the right directory paths, URL mappings and access levels.

Deploying a ColdFusion application removes a bit of the rigor. Create a directory in the Web document tree and put all the files in it. Done. Finished. That's the whole process. The first time you do one like this, you'll think twice about how to construct your next application. I can safely call myself a Perl junkie. It's a fun language to work in, and for someone with admittedly modest programming skills, CGI provides some very comfortable coding standards. I'm not likely to leave that world behind, but have found some new life for some existing applications by leveraging the power of a data warehouse behind them.

For those still not swayed to at least take ColdFusion for a test drive, I'll summarize what I feel are the strengths and weaknesses of the two Web application development strategies.

CGI Strengths over ColdFusion
Perhaps the strongest push to use CGI applications is the rich collection of ready-made resources freely available on the Web. Hundreds of free applications can be found, complete with source code. My favorite site for script resources, www.cgi-resources.com, has hundreds of free and low-cost scripts available in all the most popular languages for coding CGI scripts. Allaire has a fairly extensive tag gallery of contributed items, but ColdFusion-driven applications are hard to find, and when I have found them they tended to be a bit expensive.

CGI is largely portable. I've written CGI scripts that run virtually unchanged on multiple versions of UNIX and Win32 platforms. ColdFusion runs only on Win32 and Solaris. A version of ColdFusion running on Linux would probably balance this one.

Development and deployment price is greatly reduced. Perl and several other languages used for CGI programming are free. Most Web servers provide configuration options for CGI support. Using the Apache server running on a Linux-based system with Perl CGI programs, the only cost is the hardware. The ColdFusion application server is nearly $900, the CF Studio is almost $300. Since it runs only on Solaris and Win32, add an expensive (both to buy and maintain) operating system and very robust hardware. CGI wins this battle hands down!.

So why switch? Well, I'm not advocating the abandonment of CGI in favor of ColdFusion. Rather, I'm suggesting that this is a mature tool that deserves a concentrated evaluation.

Where ColdFusion Shines
Database connectivity is easier with ColdFusion. Particularly for large commercial SQL servers ColdFusion sets up without much additional software. Version 4.0 features native drivers for Sybase and Oracle. For anyone who has fought the Perl DBD/DBI battles, the ease of connectivity is refreshing.

Deployment is simpler with ColdFusion. Much simpler, in fact, often requiring little more than uploading files and setting up a System DSN to access (and this can actually be done through the Web interface to the ColdFusion Application Server!). CGI applications seem plagued by the permissions issue, which will differ from server to server based on the local configuration. The sites doing ColdFusion hosting at this time are still few and scattered, but the number is growing.

ColdFusion offers a true integrated development environment that rivals that of any popular programming language. This environment ties directly to the remote site out on the Web, making the process of deploying files to a production environment even easier. Table 1 summarizes the discussion above.

A number of typical tasks handled by ColdFusion are of particular interest to CGI programmers. I'll handle some of these in depth at a later date. CGI lives by forms, and forms are made effective through validation of user inputs. Sometimes we enforce our validation rules in our scripts, but this is horribly inefficient. ColdFusion offers us special form element tags that, when sandwiched inside the <CFFORM> tag, allow the ColdFusion application server to generate JavaScript client-side validation routines. The first time I used this, I was pleasantly surprised to see very clean, cross-browser-compatible JavaScript that looked amazingly like the routines I so painstakingly write by hand.

Another task I deal with frequently is sending mail. Whether sending order confirmations, announcements or simple feedback forms, I use mail in my CGI applications more and more frequently. Early on this was easy. A system call off to sendmail and messages were on their way. Then came the Win32 servers. No system mail. So I went to socket routines. Very portable, but required a bit of configuration and somewhat tedious to work with. ColdFusion bundles SMTP. The <CFMAIL> tag reads like a simple form. You put your normal mail header parameters with the opening tag and put the content of the message before the closing </CFMAIL> tag. Simply speaking, it's a thing of beauty. It gets even better since you can specify the results of a query (say, of e-mail addresses) as the "TO" parameter.

Built-in session management features, Java support, the Verity search engine, file and directory management and hypertext transfer protocol interfaces round out the more accessible and useful built-in features. While all these things can be accomplished with CGI, they don't come standard as part of the typical core language distribution. Even with a free language such as Perl, the effort spent configuring the add-on modules weighs heavily in the development time when implementing many of these features and may not be an option at all if you're running your site on a remotely hosted virtual server.

Is CGI going away? Hardly. If you want to add a few simple dynamic elements to your Web site, CGI is a great way to get started. As your needs evolve, especially if they evolve into database programming, ColdFusion is a product you can't afford not to evaluate. Take it for a test drive. Evaluation copies are available from Allaire at www.allaire.com. You can also get an evaluation copy on CD packaged with Ben Forta's ColdFusion Web Application Construction Kit - a must-have desk reference for ColdFusion developers from novice to expert.

More Stories By Jim Esten

Jim Esten (as of Feb 09) … is a work at home dad in Cedarburg, WI who occupies his days in front of a couple computer screens doing development and operations support for several hundred websites as the chief geek of WebDynamic, LLC. He is the dad of seven amazing kids ranging from a newly rolling over baby girl to a freshly minted teenage boy driver, a grade school catechist, youth soccer coach and referee, Junior Achievement volunteer and scout merit badge instructor. In a past life, Jim was an Army officer, serving at Ft Bragg, NC from 1985-1990. He holds a BA from Ripon College in Sociology and Anthropology, a Master of Science from Cardinal Stritch University in Computer Science Education and is currently purusing a Master of Arts in Lay Ministry at Cardinal Stritch. Jim is nothing if not eclectic .. his passions beyond family and catechesis including traditional woodworking (that is.. sans power tools…), old tool collecting, cooking and collecting autographed CDs of independent and small label recording artists. Mostly, he loves being at home with the family after too many years as a road warrior tech consultant for a global technology company.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.