Content area
PHP began as a "Personal Home Page" script to manage a couple of page hit counters (the developer, Rasmus Lerdorf, wanted to know who was reading his resume). In several incarnations since then, it has become a full-blown programming language, with an active community of developers that are working fast to add functionality to it.
This isn't a product review, and I'm not going to recommend any one of these solutions over another. They all work well and are about equally powerful, and they can all point to heavily used web sites built on their technology. Most sites end up basing their decisions on factors like what programming expertise they have on hand, their choice of server platform-and perhaps their feelings about Microsoft.
Server Side Includes (SSI)
The conceptual ancestor to all the other solutions listed here is Server Side Includes, which was originally a part of the NCSA httpd web server and is still built into Apache.
It was deliberately created not as a complete scripting language but as a simple, lightweight mechanism for the server to insert into a page's content such things as the contents of another file, system information like a file's size or modification date, or environment variables like the user's IP address.
Later modifications have given SSI if-then-else logic to display different content to different users, but its strength is still in tasks like including standard headers and footers across a web site and automatically displaying the date a file was last edited.
Cold Fusion
In web time, Cold Fusion is a venerable old product, dating back to the mid-- 1990s. The Allaire Corporation, which recently merged with Macromedia, got in on the ground floor of this market, when the idea of pulling the content for web pages out of a database was pretty radical. It has made it work with almost every server, on both Windows and several versions of UNIX, including Linux. Its strengths are its simplicity, allowing new users to create applications quickly, and its scalability. Cold Fusion intermixes HTML tags with tags from its own Cold Fusion Markup Language; as the file is sent, the server executes the corresponding script action and replaces the tag with the output of the script.
If you thumb through the Cold Fusion documentation, the product's focus becomes clear. While introductions to other languages usually start with managing variables and arrays, looping and conditional constructs, Allaire's Developing Web Applications with Cold Fusion talks the user through one very minimal example script and then jumps straight into querying databases.
One of Cold Fusions strongest features is that it communicates with databases solely through the Open Database Connectivity (ODBC) specification. This is an Esperanto of sorts, allowing a program to use the same code to talk to databases running under Access, Microsoft SQL Server, MySQL, Oracle, or any other major relational database platform. This allows organizations to migrate from one database platform to another without breaking all their Cold Fusion web pages.
Of the solutions discussed here, Cold Fusion is the only one you're likely to spend money for. While an express version of the program is available for free download, fully functioning versions cost anywhere from several hundred dollars on up.
Microsoft Active Server pages (ASP)
ASP is definitely the pro-Microsoft solution here. While there is third-party software available that lets it run Perl scripts under Apache, it was designed for, and built into, Microsoft's Internet Information Server and Personal Web Server, which in turn run only on versions of Windows, ASP is not a scripting language itself but a technology for running other languages within a web page. Strictly speaking, it can be used with a number of different languages, but in practice Microsoft's VBScript predominates and is considered the default if no other language is specified.
This approach allows ASP to make use of whatever programming power is provided by the underlying language, but compared to Cold Fusion it takes beginners much more quickly into the nuts and bolts of getting a program to run, rather than concentrating on the design of the web page.
PHP
Among supporters of open-source software, "LAMP" has become a mantra-- Linux, Apache, MySQL, PHP These four applications highlight exactly how much you can accomplish using only software whose developers share the code openly with others.
PHP began as a "Personal Home Page" script to manage a couple of page hit counters (the developer, Rasmus Lerdorf, wanted to know who was reading his resume). In several incarnations since then, it has become a full-blown programming language, with an active community of developers that are working fast to add functionality to it. As a comparatively young program, it still changes a lot with each upgrade; last year's upgrade from version 3 to version 4 included sweeping changes that made the language more like Perl in a number of ways, and developers are still catching up with what's new. While open-source PHP and open-source MySQL are a natural match, PHP can be configured to talk to almost any major database platform.
There are some legitimate knocks against PHP As with Apache or Linux, if your system doesn't already have it, installing and configuring it can be daunting. Perhaps an even more serious problem is that it does not use ODBC to talk to databases. It has different sets of functions to talk to MySQL, SQL Server, Oracle, and so on. If your organization changes database platforms, you need to revise any PHP scripts that talk to the database.
If you have some experience with Perl or C, you're likely to pick up PHP quickly, but if not you'll probably find Cold Fusion's markup language easier to learn. But all the browser will receive is: <p>This file last modified: 05/01/2001</p>.
This means that these scripting languages have access to resources and files on the server, but they do not have as much access to information about the browser as client-side JavaScript. Fortunately, for applications that require both functions, JavaScript can be included in the output of any serverside language, allowing the actual JavaScript code to be custom-written based on server-side information, including database results, or input from forms on previous pages.
On, and over, the horizon
Cold Fusion, ASP, and PHP are the front runners in a category of software that is variously called web middleware, in-page scripting, or application servers (loosely defined as non-CGI technologies that can process HTML forms and talk to databases using the Structured Query Language, or SQL).
This is still a corner of the software world where diversity reigns, however. Organizations with an investment in Java can use several implementations of Java Server Pages from Sun, the Apache Group, or elsewhere, to run server-side Java in creating pages. Another open source platform, Zope, is aimed at managing larger-scale operations than PHP And dyed-in-the-wool Perl hackers often use mod-perl, a software module for Apache that allows Perl scripts to run without the overhead of CGI scripts.
Pick a platform, any platform
Here's the dark secret about these scripting platforms: the people who like them, like them. The people who don't, don't. They argue with each other about which ones are faster, more extensible, more robust, or more scalable, and they split hairs over which ones are "just" a scripting language and which ones are application servers.
The most helpful advice is to stay out of such fights. All of these solutions are used to run web sites large and small, all of them can interact with the database platform you're likely to have on hand, and any differences they have in performance are less likely to affect users' response time than factors like bandwidth and the amount of memory on the server.
That's not to say there are no factors making one a better choice than others. You'll want to leverage your current server platform and any technical experience you have available to you, and you'll need to weigh some trade-offs.
If you have experience with Visual Basic and run Windows servers, ASP makes a lot of sense-but if you don't run Windows or don't run IIS, it probably doesn't. If your applications will predominantly involve SQL database connections, or if you want to support nontechnical staff in developing applications, Cold Fusion is the likely choice-but if you don't have a software budget, need to do a lot of nondatabase scripting, or run an unsupported version of UNIX, it isn't. If you have Perl developers who want to stick with a similar scripting language, or prefer to stay with free, open-source software, PHP becomes the candidate-unless you're concerned about future changes to your database platform.
And of course, if none of those solutions seem right for your situation, Perl CGI scripts still run everywhere.
Thomas Dowling ([email protected]) is a board member of LITA and a member of the Web4Lib editorial board. He currently works as Assistant Director for Library Services and a web developer at OhioLINK
Copyright Cahners Business Information, a division of Reed Elsevier, Inc. Summer 2001
