Web Typesetting, Part 7: Using Form Data

by Randy Finch

For the last two installments, I have been discussing how to create a form and parse the data submitted by a person filling out the form. In this article, I will finish up this topic by showing you how to actually use the data. Since this will be rather short, I decided to also do something I promised to do a few months ago: tell you about readers' Web sites. So, let's get on with it.

What To Do With That Form Data!?

After decoding the URI encoded form data and verifying it with the user via a Perl program, it is time to do something useful with the data. Since the data is now in the hands of a program running on a server, just about anything can be done with it. However, there are several issues you need to be aware of before making this decision.

One thing that could be done is to save the data to a file on the server for later perusal. However, for the program to save the data, it must have write privileges to a directory on the server. Since someone else will actually be executing the program, the directory must be writable by everyone. This can be a security risk. You could create a long path of subdirectories, that would be hard to guess, to get to the one you actually write to. This provides some protection since the typical Web surfer will not be able to view your Perl program and thus will not be able find out where the file is being stored. However, given that there are some cleaver hackers out there in cyberspace, this could still be a problem.

Some people, me included, would like for the data to be automatically inserted into another file that can then be immediately viewed by users. Not only does this have the same security flaw as described above, it also opens you up to having problems with sadistic surfers. Internet hoodlums could submit obscene text that could be viewed by other visitors before you have a chance to clean it up. Also, someone could submit bogus data over and over, filling up the server's disk drive. None of this is good. Of course, there are ways to handle these problems, but it would take someone with a good bit of knowledge about the server and the software tools available. I am not one of those people, and I assume most of you are not either.

Probably the best way to handle form data is to have your program Email the data to you. This will allow you to filter the content before it is posted to your Web site. Also, Emailing does not require the creation of a world-writable directory. This reduces security risks considerably. The disadvantage is that there is no real-time updating of your data file. It will only be updated as frequently as you feel like checking your Email and appending the new data.

Perl Mail

I chose the Email option for my survey form. Listing 1 shows the Perl program that is executed when the user verifies whether or not the data he or she has entered is correct. Notice that this program calls the ReadParse routine as described in the previous installment. This will create an associative array of the data in the hidden controls of the verification form.

If you remember, there were two submit buttons on the verification form. One (SUBMITRIGHT) was to be clicked when the data was correct, the other (SUBMITWRONG) when it was wrong. The if statement in Listing 1 checks the value of the latter. If it is 'Information is Incorrect', the value assigned to the SUBMITWRONG input control, then this button was the one pressed. If the SUBMITRIGHT button was pressed, then no value would be passed to this program for SUBMITWRONG.

What should the program do if the user indicates that the data he entered was incorrect? Well, obviously, redisplay the survey form so he can try again. How can the program tell the user's browser to load the survey form once again? By sending the appropriate HTTP response header. As I mentioned in the last installment, there are many different response headers available to accomplish different tasks. I previously discussed the Contents response header used for creating a Web page on the fly. Well, the Location response header is what is needed for the task of redirecting the browser to another Web page. The program line looks like this:

print "Location: http://fly.hiwaay.net/~rcfinch/survey.html\n\n";

The print statement in a CGI program sends the quoted text back to the visitor's Web browser. When the browser sees that a Location response header is being sent, it checks the document address that follows and then loads that document. As with all HTTP response headers, this one ends with two newline characters, \n.

If the SUBMITRIGHT button is pressed by the user, then the following line of code is executed:

open(MAIL, "| mail rcfinch") || die "Can't open mail program\n";

The open function opens a file handle named MAIL to "| mail rcfinch". The vertical bar is equivalent to a pipe. This is basically saying that when anything is printed to the MAIL handle, pipe it through the mail program and send it to rcfinch. Your complete Email address is not needed since the mail program is running on the server of which you are a member. If the MAIL handle cannot be opened, the program dies with an appropriate message.

Once the MAIL handle is open, then it is a simple matter to send the data to yourself. All of the "print MAIL ..." statements that follow the open function accomplish this task. You could just send the data in the Email, but I chose to send all of the associated HTML code, also. This way, when I receive the Email, I can just cut and paste the body of the Email to an HTML file containing the survey results. Notice that the strings printed to MAIL are all surrounded by double quotes. If you recall from last time, double quoted strings allow variable substitution to take place. Thus, all the $input() array variables will have their values substituted before the strings are printed.

Once the print statements complete execution, the MAIL handle is closed and a Location response header is sent, pointing the browser to an HTML file that will issue a thank you message. The code for surveythankyou.html is shown in Listing 2. Its output is shown in Figure 1.

Drum Roll, Please! The Results

When an Email is received with someone's data, it can be inserted into the survey results page. In my case, this file is entitled surveyresults.html. A sample file is shown in Listing 3. All of the text between the first <TR>...</TR> tags is the text that was Emailed to me when I filled out the form myself. All the other text I built from scratch and will typically not change. As others submit data, it will be added to this file. The resultant file will be a one column table with each row containing data from a different person (Figure 2). If you want to avoid tables, you can just create regular text with each person's data being separated by a horizontal rule.

A Closing Tip

When you create server-side Perl programs, it is a good idea to test them from a Telnet session before trying them from a Web browser. The reason is simple. If the Perl program has an error, the browser will only inform you that there is some kind of server-side error, but you will have no idea what is causing it. By starting a Telnet session on your server, you can execute the Perl program from the command line. The Perl compiler will give you information to help you track down any errors. Also, any output from print statements will appear at the console. This allows you to verify that the print statements are generating the correct output.

Presenting, Readers' Web Sites

Since I began this series of articles on Web typesetting, I have been asking you, the readers, to let me know about Web sites you are creating. Well, several of you have done just that. Let's take a brief look at each.

AMUSE

Figure 3 shows the home page of the AMiga Users Society Eastside, an Amiga users group in Bellevue, WA. It was submitted to me by Robert Iacullo. The address is http://www.serv.net/~eagle/. This site contains some nice art created by Robert and others. There are a few links to other Amiga sites of interest.

Marc Hoffman

Marc is a fellow author here in Amazing Computing / Amiga. His interest is in computer art, and he hopes to pursue a fine arts degree. His computer art, created on an Amiga, can be found at his Web site, http://www.lopernet.net/marc/Marc's_Page.html (Figure 4). He also has his rather substantial resume online along with links to other art and Amiga sites.

Midian StudioS

Charles Patterson is the person behind this site (Figure 5). Midian StudioS produces 2D and 3D art and animations on an Amiga. The Web site, located at http://www.azstarnet.com/~midian/, has many links of interest to Amigans and art lovers.

RBProductions

RBProductions is Robert B. Pigford (get it? RBP). His site address is http://ourworld.compuserve.com/homepages/cyrano/ (Figure 6). He has an eclectic mix of content at this site. Motorcycles, philosophy, writing, Amiga stuff, and more.

timt

Tim Trepanier is the creator of timt's Home Page (Figure 7). You gamers will love this site. He has a list of hundreds of cheats for Amiga games. There are also some links to other Amiga sites. Check it out at http://www.netrover.com/~timt/.

NASAU

NASAU is the North Alabama Society of Amiga Users. They are located in Huntsville, AL, just 70 miles from where I live. NASAU has been around for many years. I used to buy public domain disks from them back when Fred Fish was just starting his collection of disks. Recently, NASAU registered the domain name www.amiga.org and began their Web site. As you can see in Figure 8, they have already put much content on their site. Wayne Hunt submitted this site to me. Take a look at http://www.amiga.org.

Laser Stars

John Talbot has created a site devoted to laser stars at http://www.achilles.net/~jtalbot/ (Figure 9). These are stars that supposedly produce laser radiation. He has many articles online about this topic. Although there is no Amiga content at his site, he uses an Amiga to assist in building his Web pages.

Boy of the North

This northern boy is named Larry McGahey. Larry and I have corresponded several times over the years. As you may remember, I wrote a series of articles about CanDo programming a few years back. Larry is a CanDo programmer, also. In the past, he has sent me some programs he wrote as well as some original music files. Larry now has a Web site at http://www.net-link.net/~lmcgahey/ (Figure 10). And he's at it again. He has written a Web design program named Web Design. You can download it from his Web site. He also has available other programs and games, graphics, animations, music files (MOD format), links, and more.

</FORM>

Well, that's about it for my discussion of forms. Next time I will be discussing image maps. In the mean time check out my home page at http://fly.hiwaay.net/~rcfinch, send me Email at webmaster@rcfinch.com, and let me know about your Web sites.