|Don't ask to ask, just ask|
use CGI and die;by hardburn (Abbot)
|on Jun 10, 2003 at 14:59 UTC||Need Help??|
Ovid's use CGI or die; is something of a classic around the Monastery. At the time it was written (more than two years ago), I'm sure it was good advice. Indeed, CGI.pm is far superior to cgi-lib.pl, and definatly better than doing parameter parsing by hand. Certainly, you could be doing far worse than to use CGI.pm.
However, I wonder if it is really a good idea to recommend this module anymore. Arguments against CGI.pm are as follows:
I'll take these arguments in the order above.
1. The internals are a mess. For starters, look through the CGI.pm code. Search for 'strict'. I did this on CGI.pm version 2.752, and all I got were a few comments. This module would take a major effort to get working under use strict. Few people would suggest using a more recent module that couldn't run under strict.
2. The documentation reads more like a tutorial than a man page. The root-level POD document for any module is inevitably going to be the most referanced documentation on that module. It should thus be written to be used as a continuing referance for people who are already familer with the module--in other words, a man page. Tutorials have their place, but that place isn't at the main module document. Doing so just makes unnecessary digging for people who want to know the specifics of how a certain subroutine works.
3. It should only be used for basic CGI tasks. This is a matter of debate, and there are many promanent Perl programmers on both sides of the issue. The argument is that all those HTML-generation subroutines in CGI.pm just shouldn't be there. Plus, they are contributing to the documentation problems mentioned in #2. Perhaps it is better than printing them by hand, but wouldn't it be even better to use a templating system?
Perhaps a templating system is overkill for a quick-and-dirty CGI, in which case we are back to either generating HTML by hand or using a module to do it for us. Even if this is the case, those subroutines still don't belong in CGI.pm. Other module exist with similar functionality (see below).
If CGI.pm were reduced to param() and maybe cookie(), most people wouldn't notice the difference.
4. Other modules exist with similar functionality. This in itself isn't a reason to dump it or any other module, but if the community were to decide to move away from CGI.pm, it is important that alternatives exist. A short list:
This is certainly not an complete list. CPAN is way too big for it to be. This just lists a few of the alternatives.
Overally, I think that CGI.pm's time has passed. It is likely to be used for quite a while longer, at least until another CGI param-parsing module makes it into the core--perhaps not even then (we're still working on getting rid of Perl4 code, after all). Even so, I think it's time to recommend alternatives where it is possible to do so.
Update: Slight problem in last paragraph fixed (orginal left out "another" in second sentance WRT CGI param-parsing module).
Note: All code is untested, unless otherwise stated