CGI.pm vs no CGI.pm

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

Replies are listed 'Best First'.
Re: CGI.pm vs no CGI.pm by tadman (Prior) on Oct 30, 2002 at 04:39 UTC
If you think you can write your own CGI handling routines, try, but to do this properly, it will take a lot of time and effort that would be better spent on things that are important. Like your application. The long and the short of it is: Use CGI because it works and is practically a de-facto standard when writing Web-based applications in Perl. Any arguments that say that "CGI.pm is too hard to learn!" are simply not true. Just because you don't understand it, or because it looks complicated, doesn't mean you can't learn it in small steps: `use CGI; my $q = CGI->new(); print $q->header(); print "<B>Hello there ", $q->param('name'), "!</B>";` [download] This is typically what you do, though of course, with a lot more code. Achieving the same thing with your own "hand rolled" code is liable to be a huge chore. Now, of course, you don't have to use CGI, but if you're asking for help with a problem and the first thing you say is "I have these hand-rolled CGI parsing routines, and..." you're not going to get much useful feedback.	[reply] [d/l]
Re: CGI.pm vs no CGI.pm by dws (Chancellor) on Oct 30, 2002 at 06:51 UTC
I have never really used CGI.pm, unless there was a small snippit that I saw and needed... CGI.pm embeds a lot of hard-learned wisdom about how to correctly deal with CGIs and forms without exposing yourself to security problems. If you try to roll your own form processing code, you're very liable to commit one of several sins that CGI.pm codes against. If "unless there was a small snippet" means that you're borrowing the code that you need from CGI.pm, then you're probably in O.K. shape. You're doing "copy and paste" reuse is better than rolling your own, but not as good as using CGI.pm directly. Direct use gives you the advantage of easy update if/when new versions of CGI.pm are released.	[reply]
Re: CGI.pm vs no CGI.pm by BUU (Prior) on Oct 30, 2002 at 04:24 UTC
use CGI or die;	[reply]
Re: CGI.pm vs no CGI.pm by relax99 (Monk) on Oct 30, 2002 at 12:47 UTC
You really don't have to use CGI.pm. By saying that I mean that you should use one of the modules for reading form data from CPAN rather than coding it yourself. I believe there's quite a few modules for this purpose: CGI::Minimal (I use that instead), CGI::Lite, etc...	[reply]
Re: CGI.pm vs no CGI.pm by dorko (Prior) on Oct 30, 2002 at 06:44 UTC
What are the main advantages over CGI.pm to the regular* way of coding, without it?* <paradigmShift> I don't write a lot of Perl, but for me, the regular way of coding is to use CGI.pm. </paradigmShift> BUU is right on the money. use CGI or die; is the canonical answer to your question. Cheers! Brent -- Yeah, I'm a Delt.	[reply]
Re: (nrd) CGI.pm vs no CGI.pm by newrisedesigns (Curate) on Oct 30, 2002 at 13:25 UTC
newrisedesigns hands FireBird34 a copy of CGI Programming with Perl I don't mean to be harsh, but why would you ever avoid using something that could save you a lot of headaches and unforeseen problems? If you use taint and CGI, you'll be saving yourself from errors and bugs that you might not have ever expected. How's that possible, you ask? Lincoln Stein and his buddies keep CGI updated, so it will always be secure (as long as you download the upgrades, that is). Mr. Stein even has some information online that answers your question. I will admit, I've written some programs that don't use CGI.pm. Actually, I think I used only one of those in the real world, and it's a "random text generator" that's fed through SSI, so it needs to have a header. I used print to generate the header, instead of the header() function in CGI. Why? Using a module was overkill. However, I have another small program on my website that accepts a POST with a little bit of text in it. This text is then stored on my server and displayed when a page request is made. I used CGI.pm for that 20-liner; there was no doubt in my mind that it was needed. By accepting any input, I leave myself vulernable to all sorts of attacks, especially if I forgot to check for something in my regexp. By not using CGI, you make yourself a target. In the workplace, an employer pays its programmers to produce reliable code, not experiment in new ways to pull apart a query string or patch old code because security holes were found. John J Reiser newrisedesigns.com	[reply]
Re: Re: (nrd) CGI.pm vs no CGI.pm by FireBird34 (Pilgrim) on Oct 30, 2002 at 21:57 UTC
Thanks all for the help =) I'll take a look at those URL's and see what I can find out. Just that I've never really used CGI.pm before, but have been told to use it many times; yet without any reasons. Thanks again =)	[reply]
Re: CGI.pm vs no CGI.pm by Aristotle (Chancellor) on Oct 30, 2002 at 12:53 UTC
You will benefit from reading Ovid's excellent CGI course. It covers not only this question, but an array of others as well. Makeshifts last the longest.	[reply]
Re: CGI.pm vs no CGI.pm by BUU (Prior) on Oct 30, 2002 at 22:34 UTC
Actually, i take back what i said above about using cgi. Use CGI::Lite or CGI::Simple or something. In other words, use CGI* to parse forms, please god do not use the functions that generate html, as that is pure evil, for several reasons: Mispelled function name: this is fun to track down until you realize why you have a 'foobz' html tag being generate.. Over riding function names: what if you name a function h1, or div? imho `h1(b(i(s(test))))` is jusy ugly. But thats me.	[reply] [d/l]
Re: Re: CGI.pm vs no CGI.pm by FireBird34 (Pilgrim) on Oct 31, 2002 at 01:48 UTC
Heh, I was actually going to be taking a look at CGI::Lite aswell :) But a question on this. Why so many? Why not one main one, instead of all these variations of the same thing? Just security/simplisity reasons? At least that's what I gather thus far...?	[reply]