Editor's note--In this series of articles, Dick Applebaum discusses the evolution of ColdFusion MX, one of the hottest new Web development products, and how to get ColdFusion MX running on Mac OS X.
ColdFusion is a system for rapidly developing and deploying Web sites, particularly those that involve interaction with databases and the presentation of dynamic results.
In a few short years, ColdFusion has become one of the major players in the highly competitive environment of hosting and delivery (serving) of Web applications. There are many reasons for the popularity of ColdFusion, but I'd like to focus on those that I think are most important from a Web developer's point of view.
I've been developing Web sites since 1997. I use programming to give the sites capability beyond serving static HTML pages. Like many others, I began with Perl CGI programming and even wrote a few Perl shopping carts, for my own amusement. Sometimes, a client needed some modifications to existing programs, so I also wrote some ASP and hybrid applications.
At the server, I would design my programs so they would efficiently deliver pages in smaller, more digestible chunks.
For example, one site displayed news articles. We could have designed it to retrieve hundreds of long articles then download them for display on the browser. This would probably take several minutes and the user would likely get bored and move to a friendlier, more responsive site.
Instead, we retrieved and downloaded the title, author, and a short abstract of the top ten news articles. This only took a few seconds! The user could click on a specific article to retrieve and display the complete text in a pop-up window (another few seconds). Alternately, the user could browse through the next (or previous) ten articles or jump to the first, last, or intermediate groups of ten. Each browse action initiated another request to the server for another group of ten article abstracts.
A third option was to search the articles for such things as keywords, authors, source, and so on, to display a list of articles and abstracts that matched the search criteria. As above, the user could navigate through the matched articles in groups of ten.
With this approach, called drill-down, the user can quickly and easily browse large amounts of data and focus on the specific information desired. The user experience is an interactive "Click and Go" rather than "Click and Wait".
You might say: "I've seen lots of sites that work this way". That's the point. It's a pretty good way to design a Web site. It doesn't overload the server, the communication lines, the browser, or the user with volumes of unnecessary information. But, as we'll see, this requires extra design and programming effort.
To support this interactive user experience, some work needs to be done in the programs that run server-side. We must:
Retrieve the requested information from a database.
Cache the information on the server so it can be efficiently browsed.
Remember where each user is and what he is doing (what page he or she is on)--in other words, maintain the state of each user.
Divide the information into digestible chunks that can be efficiently and quickly downloaded and displayed on the user's browser.
Allow the user to navigate through the chunks of information presented (First, Last, Next, Prev, Specific Page, and so on).
Most of the early Web programming languages do little or nothing to assist the developer with these requirements. Many languages do not even support databases without first installing add-on components. So you end up having to do all the work yourself in each and every program that uses drill-down or dynamic data.
From its inception, ColdFusion (CF) was designed to integrate database with Web presentation. CF hides a lot of the messy details of interfacing a database. You don't need to devote your valuable developer time to understanding and programming these details. CF does that for you. Instead you focus your attention on the needs of the application. Here are a few ColdFusion benefits for our drill-down example:
With a single command (cfquery), CF will query a database and store the results in an array.
An option to the cfquery tag causes the query results to be cached in memory so you can reference the data multiple times without "Maytagging" the db server. Author's note: Early disk drives from IBM were the size and weight of a washing machine. When put under heavy load, the rapid movement of the seek arm would cause the drive to vibrate and literally "Dance" across the floor, resembling the Maytag wash machines of the 1930s.
CF provides a simple, yet powerful, mechanism for maintaining the state of each visitor to the site. You keep track using a unique set of "Session" variables for each visitor. Each visitor (and the associated "Session Variables:" is tied to a cookie or a token (provided by CF) that gets passed with each page.
Once the data is retrieved and cached, it's broken into digestible chunks (say groups of ten). Another CF tag makes it easy to iterate over the array (created by the cfquery) and extract only those items requested for presentation (as defined by the visitor's Session variables").
Paging through the information is just a re-execution of the iteration process with a different starting point for the next (or other) group of ten.
All these things are built into ColdFusion and designed to work together. They make it easy to accomplish drill-down presentation of dynamic data. So, from a developer's point of view, it's much easier to write complex programs with ColdFusion than with other programming languages.
The Web changes rapidly, and the sites that don't keep up with the changes will likely languish. An often-ignored part of Web development is the cost of maintaining a Web application over time -- usually by several different people.
ColdFusion programming uses English-language tags such as
cfMail, and so on. These are easy to read and understand. CF Programs also tend to be self-documenting. This means that anyone who knows ColdFusion can look at the program, understand what's going on, and even modify it. Sites implemented in ColdFusion can realize significant savings in program maintenance costs over the life of the application.
When a developer interacts with a potential client, the client may have only a general idea of what he or she wants from the Web site. The power and compactness of the CF language make it ideal for quickly prototyping the "look and feel" of the site to show to the client. Using CF, the developer can easily:
Design, create, and populate prototype databases if none exist.
Interface, extract, and manipulate existing legacy databases to build prototype versions.
Build dynamic-content Web pages using drill-down or other techniques.
It's a simple matter to put together such a prototype, deploy it, then demonstrate it in the client's office, or even over the phone. So, from a developer's point of view, CF helps to determine the clients' needs and demonstrate a prototype solution without investing a lot of time and dollars. And you, as the potential developer, get to "Strut your stuff".
ColdFusion has a full complement of powerful tags and built-in functions that make it easy to tackle almost any Web-programming task. By this, I don't mean that you can write macros with CF; rather, that the ColdFusion tags and functions themselves are powerful macros. To illustrate the significance of this, here's an example:
When I first became aware of ColdFusion, I wanted to test its capability by writing a "Real Application". I had recently completed a Perl shopping cart program that was about 100K of liberally commented code.
I copied this into a blank ColdFusion template (program file). Then, I went through the program routine by routine, analyzing the Perl statements and converting them to CF statements that give the same results. As I'd convert a group of statements, I'd comment out the Perl and include the CF tags intermingled with the comments.
After several hours of this, and some testing, I had an operational CF program with hundreds of lines of "Perl comments." I zapped the "Perl comments" and I had a CF program that was smaller, ran faster, and was easier to understand than the Perl original. I was amazed how easy it was to replace lines of Perl statements with fewer, more powerful, CF tags.
Consider a little routine to calculate a cookie expiration date, seven days after today's date. It's not as simple as it sounds. You must take into consideration month-end, year-end, leap year, and so on. This took about 30 lines of somewhat cryptic Perl code. In CF the replacement one-liner reads:
<cfset newdate = DateAdd('D', 7, Now())>
All in all, I was able to throw away 75 percent of the Perl code.
In this case, macro programming means replacing one for many. This is truly a power feature that sets CF apart from other Web programming languages. With CF, developers can be more productive, competitive, and profitable!
Since my introduction to version 3.0 (ages ago, in 1997-98), ColdFusion has gone through several major releases, each with its own set of new features that often setting the pace for others to follow.
The latest version of ColdFusion is part of the MX family and includes some exciting new features. For an overview, you might want to visit Macromedia's site.
For the purposes of this article, I want to focus on the most significant features of this release (in no particular order):
XML integration -- CFMX includes tools for manipulating XML data. Prior releases relied on the Web server or custom tags to process XML. New XML functions make it easier to create, manipulate, and exchange XML data from within a CFMX program.
Flash integration -- With CFMX it is easier to develop sites that provide "Rich Content" such as complex data, graphics, animation, and sound. By designing the new versions of Flash and ColdFusion to work together, Macromedia has streamlined the communication between client and server.
Web Services -- Earlier releases of CF had the capability to harvest information such as stock quotes, flight schedules, shipping rates, and so on, from other Web sites. But, the process was tedious and inefficient. The interface was problematical in that it would likely break if the target site changed its format or structure. A growing trend is to formalize the interface for inter-site communication as Web services. CFMX provides the ability to easily and efficiently publish and consume Web services.
Java Interface -- CFMX makes it possible for ColdFusion programs to coexist with, interact with, and share data with Java programs.
Speaking of the Java interface, this environment provides you with the best of both worlds:
The CF advantages of rapid development and deployment of prototypes or production applications.
The CF advantage of a short learning curve and quick-start development.
The broad acceptance and platform independence of Java programming.
The power and efficiency of the Java environment.
The ability to combine Java components from several sources (vendors) and interoperate among them in a single application.
You can develop parts of an application with ColdFusion, and other parts with Java. So, this environment can serve as a gentle introduction to Java programming. CFMX is a self-contained representation of the Web server environment (everything you need) that can be installed on a local machine with a free developer license.
"What about us who use a Macintosh for Development?"
I've always used a Macintosh to develop Web sites that use ColdFusion. But I couldn't install and run ColdFusion on my local machine. As an alternative, I could emulate Windows, and run ColdFusion under emulation. But this approach is slow and cumbersome -- not really a practical solution.
My other option was to write CF programs and upload them to a machine that runs ColdFusion, which isn't too bad. But, I still would look longingly at Windows and Linux developers who could install everything on a portable. They could prototype, develop, test, and demonstrate anywhere, anytime, with no need to connect to another machine.
Of course, this wasn't unique to ColdFusion. Other popular Web languages didn't run on the Mac either. With the release of Mac OS X, however, the situation is getting better for Web developers. Mac OS X ships with Perl, Java, PHP, and the Apache Web server. And, although not part of the official Mac OS X distribution, there are several open source (free) or commercial database systems you can download and install on your Mac, such as PostgreSQL.
So, now the Mac has a robust Web server, solid database options, and a variety of programming languages. That's everything you could ever ask for, right?
Well, except that Macromedia hasn't released a ColdFusion server that will run on Mac OS X, at least not directly. Fortunately, Mac OS X includes Java, which with a little work, enables ColdFusion MX to run directly on your Mac.
We've talked quite a bit about ColdFusion MX and Java. To help you understand how these pieces work together under Mac OS X, let's take a little tour.
All programs eventually get reduced to a series of ones and zeros that are recognized as instructions by the computer's Central Processing Unit (CPU). Each make of CPU has its own set of instructions. This means a program written for an Intel CPU won't run on A Motorola CPU and vice versa. So a software company or a developer must write and maintain a separate set of programs for each CPU they want to support. This can be costly.
Over the years there have been several attempts to eliminate the need to create a separate set of programs for every CPU manufacturer. One way to do this is to define an instruction set for a hypothetical machine (called a Virtual Machine) that's tied to no particular CPU. We then can write all our programs using the Virtual Machine's instruction set. However, to actually run our programs we must write one additional program (a Physical Machine Language program) -- one that translates the Virtual Machine's instructions to a given CPU's instructions.
We need write this translator only once, then every Virtual Program will run on (be translated to) that specific CPU. To support additional CPUs we need only write a translator for each one. There are lots of advantages here:
Your single set of Virtual programs will run on CPUs from multiple manufacturers.
You can upgrade your programs to a new CPU by simply writing a translator, instead of rewriting all your programs.
You don't really need to write the translators -- the hardware manufacturers will do this to enable them to sell their machines.
Java from Sun Microsystems is the predominant Virtual Machine -- there are translators for virtually every popular CPU -- this is what makes it possible to run CFMX on Mac OS X.
The Java Virtual Machine environment provides much more than a Virtual instruction set and a translator. Commonly-used functions and routines have been pre-written for us so we don't need to reinvent the wheel. Some examples are of built in functions are:
Draw a circle.
Search text for a phrase.
Calculate the square root of a number.
Java contains hundreds of these built-ins (called classes) and they greatly simplify our programming.
The computers of today are powerful and fast enough to run many programs concurrently. Several different programs may use a common set of business logic or services, for example:
Validate a customer's credit limit.
Log a transaction.
Update the database.
Send an email.
Rather than duplicate these functions in each program, we can package them as separate Java programs that perform them as services. Our program communicates with these services by sending messages to them and receiving results from them.
In our CFMX/Java world, all the services are written in Java, or are a Java program interface to an external program written in Java or some other language. The Application Server environment is provided by JRun, which is distributed with CFMX and also available as a separate product. JRun is written in Java. It consists of a kernel and a set of services.
We can write our own functions and business logic as Java programs and add them as new services, or write our application in Java and use the other services through the JRun kernel.
We may choose to write our Web application programs in ColdFusion -- the advantages of doing so have already been discussed. We write the program in ColdFusion Markup Language (CFML), then save it with a special suffix (.cfm) in a place that is accessible to JRun.
When the Web Server service receives a request from a browser for a .cfm template, it passes the request through JRun to the CFMX service -- we'll call this the Web Application Server service.
The CFMX Web Application Server service reads the .cfm template, interprets the CF instructions, and passes the results back through JRun. Now, we can modularize our CFML code, too. We can have separate templates and functions that can be used by making requests through JRun.
We can also use the other services available to JRun by invoking them with a CF tag, for example, a cfquery tag will be interpreted to pass a request for db services through JRun. In this context, CFMX is just another specialized service available to JRun -- a service that interprets CFML.
This is the end of our nickel tour of CFMX and Java that provides just a glimpse of the highlights. I hope I've provided you with at least a big picture of what's there and how it all works together.
In Part 2 of this series we'll explore the various components of CFMX Web site development and how they interact with one another. Part 3 will take you through the steps necessary to get a CFMX Development system installed on Mac OS X.
Dick Applebaum has been doing Web development since 1997, primarily with ColdFusion -- including his latest challenge to port ColdFusion MX to Mac OS X.
Return to the Web Development DevCenter.
Copyright © 2009 O'Reilly Media, Inc.