in reply to A "newbies" thoughts on cgi.pm...

Heh, pretty much what i expected. I would try to reply individually to most of your point, but there are so many that i would have to write a 3 page post, so let me say:
  1. var=1&var=2 would of course make var=2; (hey, it makes sense to me)
  2. a lot of my problems was that i didnt know there was sucha nice spec page (Here) And if i had known it, i probably would of ended up using cgi.pm. Nothing i saw in my various researching about it ever said 'go look at perldocs.com/cgi to learn alot more about it'.
  3. i wont show you my code because i *know* its broken, what good does having you tell me do me?
  4. 'what is it doing to the vars it slurps up' by that i mean, when it grabs all the input from STDIN and parses it, what exactly does it do? Does it convert the escaped %xx characters? Does it convert other things?
  5. no, i wasnt paid for it, it was solely for my own usage.
  6. Yes, perl may be doing things i dont know about, but i can read lots and lots of documentation about it (i didnt know there was a perl docs site!)
  7. After reading up on the perldocs site, i think i will switch my code over to cgi.pm (maybe...), But i am glad that i took the time to learn more about how the cgi protocol actually works.

Replies are listed 'Best First'.
Re: Re: A "newbies" thoughts on cgi.pm...
by Amoe (Friar) on Apr 07, 2002 at 20:39 UTC

    As a side note, if perl's binary directory is in your PATH you can usually say perldoc CGI to your shell and read the documentation offline. :)

    --
    amoe
Re^2: A "newbies" thoughts on cgi.pm...
by tadman (Prior) on Apr 09, 2002 at 17:26 UTC
    Laziness, impatience and hubris, they say, are things that make a good programmer, or at the very least, a good Perl. Hubris, though, should not mean arrogance. These questions you ask are both intelligent and ignorant. Which is to say that they are good questions to be asking, but they are easily answered by reading the documentation for CGI.pm.

    First, 'var=1&var=2' means that you have checked off two selections from a list or from checkboxes and that 'var' has both values. Of course, CGI.pm handles this elementary condition flawlessly.

    Second, CGI.pm de-escapes all input so that even if it came in encoded in RFC-23190 ROT-13 EBCDIC, you wouldn't know it, but then, why would you care? You can re-escape at any time, at your discretion.

    These two questions are merely the tip of the proverbial iceberg, and there is a whole lot of work going on under the waterline inside CGI.pm. It is probably better that you don't know exactly what it's doing, because some of the things that is has to do are quite unfortunate and unsettling, but that is how portability is achieved, especially with things like IIS.

    Simply, it will take far less time to understand how CGI.pm works than to develop a replacement that is even functionally equivalent in the most basic sense, regardless of the skill of the programmer. In fact, the better the programmer, the faster they will likely understand how CGI.pm works, and how it can be utilized effectively, which is a lot less to think about than the myriad of details and obscure workarounds involved in reimplementing it.

    They say that when re-engineering something, you can do 80% of the work in 10% of the time, but that the last 20% can seem like an Archimedian struggle, where you are moving closer and closer to completion but are never able to get all the way there.

    Of course, this does not prevent experimentation or pseudo-academic reimplementations for the purposes of discovery. However, using these academic versions in a production environment is irresponsible and naive.
Re: Re: A "newbies" thoughts on cgi.pm...
by sfink (Deacon) on Apr 11, 2002 at 01:03 UTC
    Two points:
    1. Writing your own CGI.pm or Text::Template or Data::Dumper or whatever is always a good idea, unless you're pressed for time. I didn't bother with CGI.pm for the first dozen CGIs I wrote. (I also didn't make those CGIs available where anyone remotely unfriendly might use them.) I even started writing my own module. And I refuse to agree that it was a bad idea, because I now appreciate CGI.pm more than I ever would have if I had mindlessly followed the "writing a CGI? Use CGI.pm!" advice. I know more about the sorts of problems it's handling for me, and when things break it's likely that I'll be able to immediately infer the root cause of the symptoms I observe.

      Note that I am not advising publicly deploying anything that relies on a home-grown module in an area you're not an expert. But if your aspirations are anywhere above being a mindless code flunky, you will have to reimplement a whole set of wheels. Any experienced programmer will tell you, usually with a self-deprecating laugh, of a whole set of lumpy wheels they carved themselves even though in retrospect it seems like a waste of time.

    2. The assertion that it doesn't matter whether you understand what's going on internally is ridiculous. If you follow that path, you'll find yourself in a room full of monkeys typing frantically on keyboards, changing things randomly until the compiler stops giving those damn syntax errors. We all started out that way, remember? I've inherited a lot of code from people who are still like that in a figurative sense, and that shit ain't Shakespeare.
    I know I'm reading too much into the comments I'm responding to, but I just think it's a bad idea to chastise someone for reinventing the wheel. If you manage to convince everyone, there'll be nobody left who really understands how things work. And don't worry -- they'll eventually figure out the advantages of reuse for themselves. In fact, they'll understand the advantages better because they'll know what a pain it must have been to write the stuff they're reusing. As long as it doesn't clutter up CPAN or end up on an accessible (exploitable) server, it's purely a good thing.