by Bryan Valencia

In many ways a web application is much simpler than an average Delphi program. Where a standard Windows application might be required to open, accept inputs, process, update, have provisions for cancelling, and error trapping, the architecture of a web application is very limited. There is one call to open the program, which contains parameters, and the program must return a file stream to be returned to the brower at the other end.

As you have no doubt noticed, the web is a place of hypertext documents. The word hypertext merely means that it can contain an active link to another document. In this way, by following links on web pages, you can journey all over the web.

As intriguing as that is, and considering the ability to embed graphics, sound, and other media into web pages, a standard HTML page is still a rather flat and lifeless place. Unless the webmaster constantly changes the content of the web page, you get exactly the same document every time. Wouldn't it be better if a web site could let the user decide what content he wanted to see? Let them upload their comments, sign guestbooks, answer surveys?

This is what makes for an exciting web site that users will bookmark and return to. It is called active content. While there are several ways to accomplish this, they all use a web mechanism called the Common Gateway Interface, or CGI.

CGI is a set of rules defining how data can be streamed in and out of a webserver. In essence, the rules go like this:

• CGI programs use the standard machine input (console) to accept input from the webserver.
• The results are returned to the webserver through the standard output (console) device.

So, for the purposes of a CGI application, there is one place to gather input, and one place to send output... except in the web world, input is referred to as a request, and output is called a response.

Requests have a very limited vocabulary, and a very strict format. They must contain the address the request is being sent to, the return address to send the response to, the request itself, and the parameters to be passed in.

Responses can be in any format the client's browser can interpret. If the response is a ZIP file, the client may ask the user to save or open it. If it's a GIF or JPEG graphic, the browser will probably just show it. HTML will be displayed. There is almost no limit to what can be returned to a client via a web response. As long as the client machine has an idea what type of response it is, it will be accepted.

To all rules there must be exceptions, and the first one was that in Visual Basic, the programmer was unable to capture ports. Therefore the standard was expanded to allow for a new type of CGI where the request is first written into a file, and the response is read from another file to be sent back. They called this type of CGI WIN-CGI, but they might as well have named it VB-CGI. Delphi supports it, but as far as I can tell, there is no compelling reason to use it - ever.

A CGI program is executed by the webserver on request from the client's browser, but it is also possible to write a DLL (dynamically linked library) to respond to user requests. If your application takes a long time to boot up, such as when logging in to databases, then an ISAPI/NSAPI DLL may be the better way to go.

I have several apps that are CGI EXE's, and log into Interbase on startup. The response time so far has been acceptable. There will be more on this subject in Chapter 4.

To "execute" HTML, the Client's browser mus attempt to load the document. If you open your browser and enter "www.209software.com" you will be taken to that web site. If you want to create a link to one site from another HTML page, you use the same method. In your <a href> tag, you insert "http://www.209software.com". But how can you tell the browser to execute a Delphi EXE?

There are 2 ways to accomplish this, but it's important to remember the unlike Java, the Delphi EXE program will execute on the Web Server, not the Client's browser. What difference does that make? Well, if you try to include the SYSTEM date or other system variables they will reflect the current state of your web host, not the client. Your clock may be right, but only for 1/24^th of the world.

The first way to execute Delphi CGI programs is to call them from a link or type them into the URL window on your browser. Here is an example:

This will call up a page of graphs about the hits on the web version of this book. But if you look at the source of the page, you find that within the page there are embedded calls to the individual graphs.

This brings us to the second way to use Delphi CGI programs. Their output can be embedded into another HTML page or even another CGI program's web page. The image calls look like this:

Of course your CGI programs can do other things too, pretty much like any delphi program, you just can't use the Windows API. Why? Because if you play a movie or a sound, it will play on the server. If you pop up a dialog, it will be on the server. The good news is that you can create and access disk files, the web server's registry, you have full access to the BDE - which means you can access Oracle, Sybase, Informix, Interbase, even Paradox and Dbase tables!

As for playing sounds and such, you can still do these things, but they must be HTML commands sent to the browser, not Delphi commands to the server.

As you learn the tricks of the trade, you'll find that there are few limitations on what you can do via Delphi CGI and the Web. So let's jump right in...

The first thing you need to understand about developing for the web is that the Web Server executes the programs, not the browser. You must have a web server online to develop for the web. Of course you must also have Delphi installed. First, figure out what your development environment will look like. It is foolish to compile your exe's into the live directory on the web or intranet. So you need an off line development server. My live server is co-located offsite, and I use a local webserver for development.

Of course, being Delphi programmers currently limits us to the Windows OS, and only a fool would deploy to the web on any Windows other than NT. There are several webservers available for NT. Here are some you should consider.

Once a server is installed and configured on your machine, there are a few things to take note of. Know where your server is configured to look for CGI-BIN and CGI-WIN programs. You'll need this information to set your Delphi compiler directories up.

To test your webserver, don't go to the HTML documents directory with the Windows Explorer and click on the "index.html" document. This method of loading a page transferrs the file to the browser as a file stream from the drive. See the URL in the browser? It says "file:///...". Instead, enter http://localhost. If that fails to please, then enter 127.0.0.1. This is a special address reserved for the local machine. At this point, you should see either an index of your HTML Document root directory, or a prefab welcome message. Oh, yeah, I almost forgot. If you use Dialup Networking (DUN) then you will have to dial in before you can do this. The IP addressing needs winsock.dll in memory in order to work. If you access the internet via a network, you needn't worry.

There is a text file called hosts.<nothing>, find it. Open it in Notepad. It should already contain a listing for localhost. It should look a lot like this:

The only line Winsock cares about is the last one. All the others are comments. You can manually add servers to your own computer by editing this file. Here's what I do to my development server. My domain is www.209software.com, so I chose to create a local version called 209software.loc. You can't add multiple lines for the same IP address in Hosts, but you can assign them like this...

This will allow multiple domains on your one local web server. Just don't forget to tell the webserver which name is which.

It is important to note here that the Web Server has to be told to recognize the various directories. Please consult the help for your web server to figure out it's configuration issues.

CGI programs are standalone executables that accept input from the stdin device, and stream results back on the stdout device. In Delphi terms, these devices are called the console. The good news is that the Delphi components parse all the inputs and store them in a structure called a TWebRequest. Your results are formatted into a TWebResponse structure.

It should be noted that CGI applications execute from scratch every time a user accesses them from a web page. This means that if 5 users hit the page at the same time, 5 copies of the program will be launched. If your program accesses a client/server database via a slow lan, you could see problems with the server 'timing out' before the result is sent.

I have successfully run an Interbase database on the same machine with a webserver without incident. My webserver timeouts are set for 90 seconds, and there is plenty of time to log in, retreive information, and get out before that.

WIN-CGI, as mentioned earlier, is a way of working around shortcomings in Visual Basic. VB can't read or write directly to the console, so this type of application accepts input from a temporary file, and exports it's results to a temporary file, which the webserver sends as it's response.

As far as I can see, there is no compelling reason to use Win-CGI, unless you want to stress test your hard drive.

Larger applications take time to load, initialize, log into databases, etc., so more complex apps may be constructed as ISAPI DLL's. The DLL only need load once, and after that, it waits for requests, and processes them. It is most important to use correct scoping for your variables, because globals are available to all instances running at any given time.

I also commonly hear complaints from programmers who are developing ISAPI apps, that it's a pain to get the DLL out of memory to recompile. Some programmers say they have to restart their webservers.

by Bryan Valencia

There are many databases available for use on a web site. If you aren't hosting your own site, you may be stuck using whatever the ISP has installed, and that will usually be Access. You will have to get them to install the BDE and ODBC drivers to use any database. This chapter is mostly written for those who have a level of choice over what software to install on the server side.

There are 3 items to consider when choosing a database for a web site. They are: cost, performance, resource usage, reliability, and maintainability. And to make it more difficult, most web sites use only one database system for all web data... which means that even if one app would be best in Paradox Tables, and another really needs Oracle, you will probably have to use one system for both. This also plays into the maintenance of your system, because who wants to hire Oracle, Informix, Paradox, DB2, etc. experts to keep it all running?

Let me make one caution at the outset. Most small development shops choose their database system because they have experience with it, or because they laid out money for it, and damnit, that's what they'll use. Good project analysis, however, calls us to consider all these factors, and make a decision outside of our personal biases (but you already know what database you're going to use, don't you).

So let's explore the differences between databases from a web perspective... For the purpose of this discussion, there are essentially 3 major classes of database system: File based (where each table is a file), Single File (where all the tables are in one file), and client/server (where who cares where the data is, because there is a program running somewhere that will just serve up the results you want.

These are the types of database systems we will consider here:

Ok, this kind of goes without saying, but you don't purchase a $3,500 Database package to store data for a hit counter. It's just a waste. It will cost you more to maintain than the benefit you get from using it. I worked with a programmer once who was so jazzed about client/server, that if you asked him for a rewrite of the Windows Notepad, he would have found a reason to make it access a client/server database and execute triggers and stored proceedures to work.

Also, this may come as a shock, but the cost of a big client/server database doesn't end with the shelf sticker price. Think about the cost of user support (from the manufacturer), the amount of on-site support required to keep it running, etc.

When you use the web, what do you do when you click on something, and the browser says, "contacting host", "host contacted, waiting for reply"... You wait. I will wait about 90 seconds max before I click onto something else. Many people click away well before that. Most will flag the site in their minds with a "terrible" sticker, and not return. On the web, speed and convenience are everything. So when you set up your database, speed test it. A 45 second response time (from clicking in, to seeing the result) is good, 30 is better, 10 is godlike. If you buy a big client/server package, and when you log in to your database over the LAN, if the login dialog takes 35 seconds or more to go away, you are going to hack the users off.

Actually, what you are doing is committing yourself to write only ISAPI DLLs that login at the beginning of the day, and stay logged in all day. Of course this makes you more vulnerable to network outages, so you'll be writing code to check the connection, and reconnect if it gets dropped.

I am not saying that all client/server databases are too slow, in fact, I use Interbase on the web for my database apps. I am just warning you to check the actual speeds before you commit to a database system.

All applications use resources. Resources cost money. Make sure that you use a database system that can coexist with your code, webserver, and OS without eating all the memory and system handles for lunch.

When testing web apps, use the Task Manager to keep an eye on peak usage. If it gets over 90%, you have to either plan to upgrade or trim something down.

This is pretty much a no-brainer, but this one is the reason I don't download a freeware database server for my web development. I know the systems I use, and I know that they have high reliability and quick error recovery built in.

A database system that is difficult to maintain is fine as long as it rarely breaks down, right? I twice had to do some work with a Visual Foxpro database, and in both cases it would drop some indexes about once or twice a day. It was simple to fix this problem, but it was a constant nightmare to keep up with it. AND... every time the indexes broke, the USERS were the ones calling me saying the system sucked.

I point this out to say that maintainability is a factor, but only as it relates to reliability. Ideally we want both.

I do apologize for taking 5 chapters before getting to any actual Delphi code, but I tend to ramble. So before I wax poetic over some concept, let's do some sample applications.

In this example, we are going to say Hello through the browser. For this, you'll need to have your webserver running.

Ok, Launch Delphi, and do File|New.

Ok, for this demo, click the default property to true, and go to the object inspector's events tab. Then double click the blank in the right column, and a handler will be created.

Modify the handler so it looks like this:

Now select Project|Options, and on the Directories/Conditionals tab, set the Output Directory to the cgi-bin directory for your server.

Do not hit F9 or select File RUN. That would launch the application with no input, and cause an error. Remember that web requests are highly structured, and "" doesn't fit the spec.

Ok, assuming we have it all running, look at the "Hello" page you got back. View the source of the page. Note that you got back exactly what you said to send. There are no headers, no HTML at all. Now view the source for the frame this text is in. It's LOADED with HTML commands. I know. I typed them all in!

The next thing we'll do is create a correctly formatted HTML document to send back. I won't go overboard on this, because there are exactly 23,432 books available to teach you how this is done.

"MIME" stands for Multipurpose Internet Mail Extensions, which is a specification for formatting non-ASCII messages so that they can be sent over the Internet. Almost all e-mail clients support MIME, which enables them to send and receive graphics, audio, and video files via the Internet mail system. In addition, MIME supports messages in character sets other than ASCII.

There are many predefined MIME types, such as GIF's, WAV's, and JPEG's. It is also possible to define your own MIME types.

In addition to e-mail applications, Web browsers also support various MIME types. This enables the browser to display or output files that are not in HTML format.

Here are the MIME settings from my web server...

Every response sent from your server to a brower contains a MIME description, either explicitly or by reference (from the file extension). This can be set in Delphi web responses like this:

This tells the browser that the response is a jpeg image, even if the filename is "FILE.HTML".

Of course I presume the virtual path to your cgi-bin directory is /cgi-bin. If yours isn't then you have to locate it yourself.

Here is the full source code for mimedemo.

The HTML page is a very simple thing. It is a text file (or a hypertext file), with sections the browser interprets. It is also a heirarchical arrangement, meaning that certain things can only exist in certain contexts. Kind of like Delphi, where you can't do this:

Likewise the HTML anatomy has a certain context that the various browsers expect to see.

Ok, the main sections for this page are laid out like this.
<HTML>
<HEAD>
(all the meta tags go in here)
</HEAD>
<BODY>
(the text of the page goes in here)
</BODY>
</HTML>

This was just a sample. There is a different structure for framesets, and we don't show any tables, data entry forms, embedded images, or graphics. For most uses, however, this is the basic layout of an HTML page.

Next is the basic layout of a frameset page.

Note that instead of a section for the <BODY>, that there is a definition for a <FRAMESET>. Actually, a <BODY> section can be added after the frames, so that browsers that don't support frames will display that HTML text instead.

The default pages that load into the framesets are noted in the <FRAME SRC="..." NAME="..."> sections, where the SRC is the filename of the page to load in, and the NAME is the name used to identify the actual frame in your links.

The NAME= is extremely useful when you create a link, because the default target of a link is _self.
so, <a href="/page1">CLICK</a> is the same as <a href="/Page1" target="_self"> CLICK</a>. The valid targets for a link are:

• TARGET="_blank" (new browser window)
• TARGET="_parent" (one up from here, frame sets can be nested)
• TARGET="_self" (the same frame the link is in)
• TARGET="_top" (the whole current browser window)
• TARGET="PAGE NAME" (Any named frame that is already opened)

In the case of the frameset above, our choices for PAGE NAME are "Chapters" and "MainText".

There are 2 really good answers to this problem. Make it so you can call your frameset with a query parameter, like this http://www.209software.com/cgi-bin/index.exe?page=hints. Alternately, there is a Javascript command you can put on your HINTS page that says, "If I am outside my frame, Load the frame set!

The header contains items which are not shown in the body of the text of your HTML document. There are several meta tags that are expected to be found within this section of your web page.

Here are the header sections from some famous pages...

Ok, there are a variety of things in the header section of the HTML page. There are meta tags, comments, style sheets, and even Javascript. I have searched the web for additional items that can be included in the <HEAD> section, but there is no definitive list that I can find. So here are some that I know of.

Essentially the header is to communicate to the outside world what your page is about, without showing it to the user. For example, you can...

• tell search robots how to categorize your page
• tell the browser to reload the page every (n) seconds
• tell the browser to display a title in the title bar
• tell the browser to preload a list of images
• set up for using Javascript

Comments in HTML can exist in any section, and they are completely ignored by the browser - almost. a comment begins with a <!-- and ends with -->. There are some server commands that exist as comments, so they'll get ignored by older browsers. If your server has Server Side Includes set, then the command <!--#include virtual="MainMenu.shtml"--> will tell the server to parse (or read) the file, and instead of this comment, it will place the contents of the file "MainMenu.shtml".

In general, meta tags tell search engines and browsers about the page or frameset. There are also some browser commands that can go in the header section.

There are some common things that can happen in Javascript in the header section. One common thing is to preload the alternate button images that appear when the user mouses over them. To prevent the image from having to load when the user touches them, Javascript can preload all the images for quick response time.

I don't use style sheets, but they can be specified in the header section as well.

The body section contains the content that is intended for the user to see in his browser. Apart from HTML tags, which usually format the display, most everything in the body section is intended to be displayed. There are tags to display images, animations, play sound, and links to other web pages.

Its the tags that turn a document from text into hypertext. Here is a quick overview of the most common HTML tags. It should be noted that like Delphi Pascal, HTML tags are not case sensitive.

In general HTML tags have a begin and end tag, in the format <tag>...</tag>. The tag is always the beginning, and /tag is always the end. There are some tags that have no ending tag, like the hr or "horizontal rule" (line) tag.

Many HTML tags have optional parameters. These are placed in the begin tag. For instance, a hyperlink tag is <a>...</a>, but it's useless unless until it has an address to link to.

This was intended to be an exhaustive list, but there are just way too many HTML tags to note here.