If you look through the first few lines of the script, you'll see that it begins much as do the previous samples. That's a little bit misleading ... the main body of this script contains only about 20 lines, including comments and white space, that generally construct the environment for the script as a whole. This main body is used as an event handler, reading the environment and passing control of what is done and what is directed back to the browser to the appropriate subroutine (those chunks of code that begin with a sub and the name of the subroutine, and that are enclosed by curly braces ({}).

There is nothing mysterious about subroutines - they are structures of code that perform some conceptually well-defined function. Sometimes the subroutines perform routine actions that you know you are going to use throughout the application. For example, in other contexts I've defined a subroutine that does nothing more than remove white spaces from the beginning and the end of a string. That can be done quite easily with Perl's regular expression matching capability, and there are those who feel that simply doing the regexp (the shorthand way to refer to a regular expression match) is just as legible as defining a subroutine that does the same thing, but at the time, and probably even now, I felt that an appropriately defined subroutine produced more legible code, especially because in that context I was going to be doing a lot of them. The modules used in Perl scripts essentially consist of collections of subroutines oriented toward a specific set of tasks associated with a given area. (In object-oriented parlance, subroutines are referred to as methods. In most ways, the difference is not a whole lot more complicated than that. We may get into that in more detail at some point later.) I am ultimately likely to turn our scripts into a module. In other circumstances subroutines represent chunks, like these, that are executed conditionally. In all circumstances, the primary purpose of subroutines is to increase the legibility and maintainability of the code. As you familiarize yourself with this script you'll see that it could be structured with those chunks defined as subroutines included in conditional statements in the main body of the script. Doing that, however, is much more difficult to read and maintain. There is a term for doing things that way - it's called writing spaghetti code, which refers to the fact that it is difficult to unravel ... you can't tell where it leads. I've written some spaghetti. We all do. In fact, it is possible to make more use of subroutines than is appropriate, and to "spaghetti-ize" your code by losing all sense of what is going on by sending execution through level after level of unnecessary subroutine calls. Programming can be a lot like writing - it's just as possible to lose the reader by being too esoteric as it is to lose them through incoherence.

So am i doing that? Back to the script. The parameter that controls the script is named action. The first step the script takes after instantiating the CGI object $forms (instantiate means create a new instance of the object class, kinda like saying $sammy_sosa=new baseball_player();) is to retrieve the value of the action paramter from the CGI environment and put it into the $action scalar. If there is no action paramter in the environment, this is assumed to be the first pass through the script and the value "start" is assigned to the $action scalar. (I'll get to how the action parameter gets into the environment in a little bit.)

In a sense, the next three lines are the heart of the script, because in these three lines execution is dispatched to the appropriate subroutine. These lines are the traffic cop, or the railroad yard switch if you prefer that metaphor, of the application. If the value in the $action scalar is "start", execution of the script is sent to the sel_form subroutine, which sends back to the browser the html for the page that prompts the user to select the number of entry forms they wish to have displayed on a single page.

If the value of the $action scalar is set to "enter", execution is sent to the get_form subroutine, displaying the selected number of forms on a page. To this point, I've used the term "form" to refer both to the html/cgi form and to an individual set of data elements grouped together on the form and representing, essentially, one row on one table in the database. (Although these entry forms could just as easily represent a composite record drawn from several tables ... the destination or source of the values in the form elements are not germane to this current discussion.) The html/cgi form is a construct created by the W3C html specifications to represent an area in the browser pages that is used to exchange data between the browser and the server. In that sense it is less concerned with a form in the sense of a data entry tool that it is with defining "form-ness". To use another analogy, this State has a body the purpose of which is to anoint the "form-ness" of any state form, rendering it official. The html/cgi form is like that, less concerned with what's being moved around that that it can be moved around. The data entry form, however, is explicitly concerned with what is being moved around, and is probably a great deal more like what you are used to when you think about a form. Just keep the distinction straight in your own mind, and you won't have much difficulty.

Should the $action scalar hold the value "store", execution will be directed to the store subroutine. (Makes sense, huh?). Currently, this subroutine simply writes the entered records into the a comma-delimited external file as described in the preceding section, and generates a page confirming the number of records that have been written.