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
| [reply]
[d/l] |
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. | [reply] |
Two points:
- 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.
- 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.
| [reply] |