NB: These pages were mostly written in 2001 or so. The résumé dates are accurate but the code is aged and unlike whiskey, 8 year-old code doesn't usually taste better. For a look at my current skills and to see my CPAN modules, sample code, and code discussions, please see these pages instead: Perl resources and sample code and PangyreSoft.
CGI with dispatch hash
Social links
View Ashley Pond V's profile on LinkedIn
Miscellaneous
CGI tutorial

A really nice, short, straightforward tutorial to CGI is Ovid's "Web Programming Using Perl" Course.


Other pages

Description

This is a simple CGI (Common Gateway Interface) script using a dispatch hash of actions to subroutine references for logic flow and user feedback/verification. Though only a basic demonstration, its structure is ideal for extremely robust, complex CGIs of any length (even thousands of lines).

Perl was the defacto language of CGI for several years. CGIs can be written in any language that the server side supports or client side languages like JavaScript. Perl may still be the most widely used CGI language but has lost ground to other languages, especially PHP which was created specifically for web scripting. Perl has lost ground to other languages because perl CGIs, being interpreted programs, could not scale well. They had to be compiled each and every time they were executed, dragging servers down as traffic went up. Increasing acceptance of mod_perl has changed perl’s reputation from easy, powerful, but slow, to easy, powerful, and fast.

The dispatch based code here is an example of a programming style for medium to large projects, or projects that may grow arbitrarily. As such, it’s not that short. It’s a bit over 100 lines of code. Small projects can sometimes be coded very compactly. File Viewer has an example of a CGI script that can do quite a bit in less than 10 lines.

Discussion

Like all CGIs, it needs to be installed with a webserver that allows executables. Feel free to give it a try on your own server (Apache is excellent, free, and will run on almost any computer if you’re looking to set up your own webserver). It’s all standard Perl as long as you have CGI.pm (if you have an older version you might have to change the “use CGI …” from “:standard” to “:all” because “:standard” in older versions does not import the table tags used).

There are many obstacles to good, clean, and readable CGI coding. Most of them have to do with program flow/logic and user feedback/validation. Compounding the problems is the stateless nature of web pages.

Often CGIs become unreadable strings of a dozen if/elsif blocks with all kinds of &&s and ||s testing parameters and controlling flow. A script may need to be run twice before any output is sent to the browser because it must be validated first, otherwise error/feedback messages which were found last would necessarily be printed last, below the fold, where they will never be seen. The CGI can be as frustrating and unpleasant to use as it is to maintain.

The code above shows an approach that solves all these problems (except session management which is definitely non-trivial). This approach is essentially cracking open the same logic of mod_perl script handlers or a module like CGI::Application. It is absolutely the way to go for any CGI that needs to be interactive or bigger than 100 lines. Many of the largest and most trafficked websites use the same style.

The layout of the script allows user feedback and internal script redirection to be easy and easy to follow. The complicated logic trees are gone—folded into modular dispatching of actions and their related subroutines. We keep state with hidden fields; usually only needing one. Any subroutine that requires validation has its logic easily encapsulated in a verify subroutine which either returns with feedback or proceeds to the next step.

Extending the script is as easy as adding a new subroutine. No real logic changes are necessary.

Another prime benefit of this style is the GET requests (with the URL) are made trivially easy and they act the same as the POST. So you won’t get weird behavior and it has a sort of built in security enforcement. You have to consider URL manipulation since you’re using GETs and therefor you’re more likely to keep your script secure.

If you haven’t, try the script so you can see how it easily it mixes submit buttons and hyperlinks for control.

You can see there is no -w switch in the CGI, though the script uses strict as all code meant for production should. For CGIs the -w can fill up your weblogs with “Use of uninitialized value…” or “Ambiguous use of…” Some of these innocuous errors can arise long after you did the script when some small change to a related part of Perl happens. Because of this, I develop the CGI with -w (and usually the -T but that’s too big a discussion to jump into here) and take it out when the script is ship-shape and ready to start using for real. That keeps the sysadmin from carping about the weblogs filling up with megabytes of useless information.

Search these pages via Google
Text, original code, fonts, and graphics ©1990-2009 Ashley Pond V.