Re: mod_perl with Apache::Registry with CGI.pm design considerations

[BigJoe]

I have been researching mod_perl and how to migrate my older perl scripts to it. What I have found are a couple of things:

1. Always use strict; and turn on warnings -- This will show you if a var will fall out of scope
2. Always pass any variables to a sub -- This will make sure none of them become global.
3. Creating a .pm file with your functions will allow Apache to handle them better.
4. Instead of use CGI; do a require CGI; -- This is supposed to destroy any "Global" variables created or use by CGI
5. Turn off KeepAlive -- (Unless you need it like me :(
6. Apache::DBI is great!


--BigJoe

Learn patience, you must.
Young PerlMonk, craves Not these things.
Use the source Luke.

[hacker]

Thank you for the advice. As a rule, I use the following in my CGI:

   use strict;
   use warnings;
   use diagnostics;
   ...

In httpd.conf, I use:

   PerlTaintCheck On
   PerlModule Apache::DBI
   PerlModule Apache::StatINC
   ...

<Files ~ "\.pl$">
   SetHandler perl-script
   PerlHandler Apache::Registry
   PerlSendHeader On
   Options ExecCGI
</Files>

I've been running the script under -T -d also, at the shell, looking for culprets. I've managed to cut it down into a smaller subset of functions, no graphics, no CGI.pm-driven HTML, and the problem went away. Now I have to start adding bits to see when it occurs again.

[Anonymous Monk]

Yah. you may use strict, but you're not really using it. You pre-declare all your variables up-front, like you're writing C code. Declare your variables at the last possible moment! That way, you make sure that the scoping is as tight as possible.

Also, don't use diagnostics in a production webserver. That's extremely expensive and, almost always, completely useless. All it does is extend warnings. If you're programming enough, you know where the problem is just by seeing the brief warning text.

A piece of advice - learn modules. If you start to break 10k lines, you really start to want them. After 20k-30k or so lines in your web application, modules become a necessity. There are simply too many places a web application can go wrong for you to have to try and trace which copy of this block of code is wrong. I've seen savings of 80% in time and 95% in lines of code maintained by (intelligently) shifting to modules. And, if you shift to an OO system, you can save up to 99% in terms of lines. (These are not exagerrations - at my prior job, those were the numbers.)

[perrin]

Don't do a 'require' CGI instead of a 'use'. If CGI.pm is having trouble cleaning up, it isn't because of that.