Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

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

by BigJoe (Curate)
on Jun 14, 2002 at 12:42 UTC ( #174479=note: print w/ replies, xml ) Need Help??


in reply to mod_perl with Apache::Registry with CGI.pm design considerations

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!


  7. --BigJoe

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


Comment on Re: mod_perl with Apache::Registry with CGI.pm design considerations
Re: Re: mod_perl with Apache::Registry with CGI.pm design considerations
by hacker (Priest) on Jun 14, 2002 at 14:03 UTC
    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.
      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.)

Re: Re: mod_perl with Apache::Registry with CGI.pm design considerations
by perrin (Chancellor) on Jun 14, 2002 at 14:32 UTC
    Don't do a 'require' CGI instead of a 'use'. If CGI.pm is having trouble cleaning up, it isn't because of that.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://174479]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (10)
As of 2014-09-02 09:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (21 votes), past polls