working under mod_cgi and mod

Miguel has asked for the wisdom of the Perl Monks concerning the following question:

Esteemed Monks,

I am re-writing a large (10s of forms, many templates, complex authorization rules, 10s os lists, many different file formats (png, xml, xls, pdf) to create and retrieve on the fly) web application purely based on mod_cgi. Actually, this app works well altought not so fast as I would like.

I am writing everything from the beggining trying to optimize my code to work under mod_cgi and mod_perl (with Apache::Registry). And here is where I'm stuck: how to deal with CGI (params requests) in a manner that works under both environments without writing a lot of specific code for each mode?
Is using a web app framework the 'only' solution?

Comment on working under mod_cgi and mod_perl

Replies are listed 'Best First'.
Re: working under mod_cgi and mod_perl by perrin (Chancellor) on Aug 29, 2007 at 15:42 UTC
The CGI module works correctly under both. If you do want a framework that is light enough to work with mod_cgi, CGI::Application is a good choice.	[reply]
Re: working under mod_cgi and mod_perl by ikegami (Patriarch) on Aug 29, 2007 at 15:43 UTC
CGI's parameter methods will work with Apache::Registry scripts and CGI script (and I think with mod_perl handlers too).	[reply]
Re: working under mod_cgi and mod_perl by CountZero (Bishop) on Aug 29, 2007 at 16:10 UTC
The documentation of ModPerl::Registry says : This module emulates the CGI environment, allowing programmers to write scripts that run under CGI or mod_perl without change. Existing CGI scripts may require some changes, simply because a CGI script has a very short lifetime of one HTTP request, allowing you to get away with "quick and dirty" scripting. . As far as parameter processing goes, there is no change under mod_cgi or mod_perl, but there are a number of other issues to look into, such as not using global variables since they do not (always) get reset for each request. On the other hand everywhere using lexical variables (`my`) can get you into even more subtle traps as they might get persisted through closures. CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James	[reply] [d/l]
Re^2: working under mod_cgi and mod_perl by Miguel (Friar) on Aug 29, 2007 at 16:18 UTC
On the other hand everywhere using lexical variables (my) can get you into even more subtle traps as they might get persisted through closures. That's exactly my problem. I don't have 'global variables' flying around. Everything is done through methods. But I'm having a lot of troubles with forms and getting the correct values from $Q->params. Under Apache::PerlRun everything works OK, but not on Apache::Registry.	[reply]
Re^3: working under mod_cgi and mod_perl by agianni (Hermit) on Aug 29, 2007 at 18:47 UTC
How are you initializing $Q? I'm assuming it's a my $Q = CGI->new(), but is your code set up so that happens on every execution? I've seen this kind of problem when moving to mod_perl. For example, if you have a method that's returning your CGI object for you, make sure you have an initialization method that sets that at the start of each response. `perl -e 'split//,q{john hurl, pest caretaker}and(map{print @_[$_]}(joi +n(q{},map{sprintf(qq{%010u},$_)}(2*23074993,51016415261,75979 +36997,13177145131,3*26789167*181))=~/\d{2}/g));'` [download]	[reply] [d/l]


Just another Perl shrine
	PerlMonks

working under mod_cgi and mod_perl