…use these to jump around or read it all
[The thank_you Subroutine]
[Modular]
[Assignment]
We’re in the home stretch now. At the end of these primers, you’ll know how to grab form data, send and alter email messages, and post and alter virtual HTML pages. What more could you ask for? Another assignment, you say? No problem.
The thank_you Subroutine
Here it is, taken right from the Guestbook script.
sub thank_you {
print “Content-type: text/htmlnn”;
print “<HTML>n”;
print “<HEAD>n”;
print “<TITLE>Thank You!</TITLE>n”;
print “</HEAD>n”;
print “<BODY BGCOLOR=#FFFFCC TEXT=#000000>n”;
print “<H1>Thank You!</H1>n”;
print “n”;
print “<P>n”;
print “<H3>Your feedback is appreciated.<BR>n”;
print “<P>n”;
print “</BODY>n”;
print “</HTML>n”;
exit(0);
}
This little section shouldn’t take too long to explain after the last Primer. It’s built the same way as the email address, with one difference. Notice we didn’t open a filehandle. We didn’t because we didn’t need to.
The first line of the subroutine looks like this:
That code informs the script that what follows in going to be text that should be rendered as HTML. If you didn’t have that line, nothing would show up in the browser window.
Rule of Thumb: If you’re going to create a virtual page with a PERL script and you want it to show up in a browser window, you start the HTML code with that line. Always.
Past that first line, it’s nothing more than an HTML page created with print commands. Remember to continue to follow the rules of PERL. There are double quotes around the text and each line ends with a semi-colon.
Make sure your HTML page is fully formed! You may not use head tags or end the HTML on your basic HTML documents. Here – do it. Make the document that the script creates well-formed. That means follow the rules.
The exit(0) wraps up the page and tells the script that it’s done writing here.
Notice that the subroutine name is followed by a curly bracket. The end curly bracket is at the very end of the entire subroutine. Make sure you keep that when you alter the code.
Modular
PERL is wonderfully modular. The script you just beat through did three things. Each of those three events is, in and of itself, a module. As such, they can be broken out of the script and called for at a later time.
Let’s go back two primers to number three. Remember that short bit of code that grabbed the form data and delineated it for us? Well, that code will play with the data from any form no matter how many form elements it has. We only had four in this small example, but the number doesn’t matter. I’ve run surveys with fifty questions and used the same code to grab and delineate the mail.
Because that code is so set in stone, there’s really no need for you to copy and paste it into every PERL script that will deal with form data. You can make it a module that is called upon by any script that needs it.
Here’s how you do it…
Take the full module that will grab and delineate the form data. That’s everything between the bold text shown on the Guestbook script.
Take that text and paste it into a text editor and save it under a name that describes what it does.
Important!
The file is still in PERL, but it is not a CGI. Make a point of saving the file with the extension .pl.
For instance, you copy that form module, paste it to a text editor and save it as form_grab.pl. There is no need to put a path to PERL or anything other than the module itself.
FTP the file to your cgi-bin. If you are not using a cgi-bin, FTP the file to the same directory where your PERL script are placed. Both the CGI that will call for it and form_grab.pl must be in the same directory.
Set the permissions on form_grab.pl to 775, same as the CGI that will call for it.
Call For It
Now, each time you need form data grabbed and delineated, you simply call on that module through the command “require”. Here’s the format:
Think of the command as a Server Side Include. The text that is found within “form_grab.pl” will simply be “written” to the PERL script calling for it.
Now that you’ve got the module, you simply call on it whenever you want form data grabbed and delineated.
Exception to the Rule
The thank-you page we talked about in this primer contained a subroutine. Lets say you wanted a stock thank-you page for ten different forms. You could easily set the code above to its own module. For the sake of argument, let’s name it “thanks.pl”.
Now, when you call for that module, it has a subroutine, so the call must include that. It would look like this:
require “thanks.pl”;
&thank_you
First we call on the module and then tell the script what subroutine it is to use. Since the code that grabbed the form didn’t have a subroutine surrounding it (Yes, it could have just as easily had one – it’s just a matter of setting a name and surrounding it with the curly brackets), we didn’t need to call for one.
Primer Four Assignment
Let’s see if I can’t get you thinking here. Can you set it up so that you add a form element to the HTML page and then call on it in the virtual page?
For example, on the HTML page, add an input box that asks the user to put in his or her favorite food. Then, have the virtual thank-you page say that you’ll send someone right over with some of that food. Of course, mention the food by name.
Yeah, I know it’s corny, but I’m a corny kind of guy. Can you do it?
[The thank_you Subroutine]
[Modular]
[Assignment]
