Re: A "newbies" thoughts on cgi.pm...

[Corion]

I know how you feel - for your specific purposes, it seems much easier to do "just the job at hand", instead of bringing in the big guns that do much more than you ever thought you wanted.

I'm currently exploring the Coro module and I'm adapting other modules, for example HTTP::Daemon to use nonblocking sockets via some glue socket code. It would be much easier to code my own HTTPd (and I already have done so). So why do I spend my time writing a IO::Socket subclass instead of simply writing a new http daemon ? I do this because the Perl modules give me leverage - the possible errors I will make by misreading the RFCs and the possible incompatibilities I would encurr with the vast varieties of web browsers have already been worked out with HTTP::Daemon, and I don't have to worry about the majority of them - plus, HTTP::Daemon is maintained by someone other than me, so all my dumb questions about it go to that person instead of myself.

The points you criticize aren't really that valid, as CGI.pm already can deliver your parameters as a hash, and where is the sense in having several identically named parameters, if you only care about the value of one of these parameters ?

If you bring in security, there is only one answer - there never is enough. You don't want to roll your own without having studied the existing solutions and knowing where they fall short. The approach of fixing a hole when it's been found does not apply in security, as it may then be already too late, and your mailserver already has sent out several thousand mails in your name all over the world - something you might want to avoid.

Of course, the learning experience is there with rolling your own version, but for my part, I'm content that CGI.pm provides me with everything I need in an easy fashion (and the documentation for CGI.pm answers all questions I have about it except why they used ugly AUTOLOAD style).

perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ;    # The  
$d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider
($c = $d->accept())->get_request(); $c->send_response( new   #in the
HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' #  web

[graff]

I'm content that CGI.pm provides me with everything I need in an easy fashion (and the documentation for CGI.pm answers all questions I have about it

Well, with >3K lines of output from "perldoc CGI", yeah, I hope that would answer all possible questions, but it does present a daunting hurdle for anyone who hasn't used it yet. This is a problem inherent in any big module that does everything in a big domain. For a module like DBI, this is perhaps unavoidable; if it doesn't cover everything, it won't usable at all. But I wonder whether CGI.pm might be better if it could be broken into smaller modules that could be documented more clearly and learned more easily. (Can it be?)

I've only used CGI.pm once myself, and because I'm comfortable with Perl and big man pages, the module saved me a good bit of effort and grief. Still, my trial-and-error cycles tended to dominate over getting things right based on the documentation. Next time I need to do this sort of thing, I'll try CGI::Lite (or something of that nature) first, and hope that will meed the need.

If I end up having to use CGI.pm a lot, and easier versions don't work out, I'll probably write a wrapper module for myself -- something that will "use CGI;" and provide just the methods that I really need, in terms that are easy for me to use and remember. Then, hopefully, I'll never need to look at the CGI man page again. This is a good exercise for a newbie: write something that makes it easier for you to use a monster module.

[tachyon]

CGI::Simple vs CGI.pm - Is twice as fast good enough?
RFC CGI.pm refactoring

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print