First off, the disclaimer. I would say that i am fairly new to perl and programming in general, only starting to use it semi-seriously in the past 6 months.
Then you should be made aware that many monks here (a lot of the regulars) program for a living (which they tend to take seriously), and in perl for that matter, or at least have a job at which they can use perl, and do, quite liberally.
But anyways, seeing that 'use' is such a favored mantra here, i thought i might introduce a different perspective on the matter.
Great. Perspective is always welcomed, but not always appreciated (be aware -- relevant fact before fiction ;)
Also i would like to say that A) I recently made a cgi type application, and no i didnt use
Great, for whom did you make this application? Were you paid?
B) no my cgi-parsing routine isnt nearly as robust and secure as
I so hope you did not get paid for this (and it's not running live in public someplace).
, so i wont show it to you.
One final caveat is that all this is from memory at this point, and from my experiences, so if something works a little differently then i remembered.. sorry.
Excuses excuses. If you're going to bother stirring up trouble, be prepared (and always expect plenty of tounge-uh-text-lashing).
Why i didnt use cgi. Because it did things that i didnt know about.
Quick, don't move ~ you are using a computer, it's doing things you don't know about (++mirod) you're using perl and it's doing things you don't know about ... i'm pretty sure you will have to live in a bubble, yes in a bubble!
For example, . When you 'use', everything in is sucked away!
Not true (use CGI don't do that). Things don't get sucked away until you say new CGI (OO interface) or invoke one of the functions (function interface). Yeah I know i'm missing the point.
What if i dont want everything in stdin sucked away?
Well what if? Are you going to redefine how CGI works (the interface, not the perl module, it's got a structure to it you know). Give me one good reason for not wanting to do that.
How do i tell what was sent via 'get' and what was sent via 'post'?
It's in the documentation.
What exactly is doing to the vars it slurps in?
It gives them a lap dance (what kind of question is that? what do you do to the vars once you slurp them? what vars? cgi is just reading from STDIN, trying to make parse things as CGI -- open up cgi and see, as if it mattered)
I realize i could look at the source of, but since its something like Six Thousand lines, its a little hard to find exactly what is doing what.
Yeah, maybe, but if you really wanted to know ... there is at least 3 CGI:: modules based upon CGI that do this reading from STDIN part well, so you could just look at them (like CGI3 or tachyons CGI::Simple).
Also, what is with the param('paramname') usage? It just doesnt make sense to me, i prefer a hash.
So make a hash ... Somebody already said it, and I'll say it again, read the documentation. If you need a lesson, there is an excellent guide here.
You may not, but isnt the motto 'timtowtdi' (or however thats spelled).
Yes, the motto is TIMTOWTDI, but the motto is also do it right.
And (unless im mistaken) if you have say, 'name=soemthing&name=blah', wont return an array for param('name')?
It will return a list. No function can ever return an array. At most, one can return an array reference.
What if your code doesnt want an array, what if you just want a nice little scalar value? Again this comes under the heading of 'what is it doing that i dont know about?'.
It's called conforming to spec.
#How's this for a nice scalar value? perl -MCGI -e"print scalar CGI->new(qq{1=2;1=3;})->param(1)"
Alot of arguements against using your 'home rolled' input parsing libs revolve around security, and lack thereof.
You also forget all the ignorant masses wondering why their home-rolled version isn't working correctly ( I for one do not like providing help to people who don't want it).
Yes, using your own solution may be less secure, but you can fix that!. Find an exploit (such as the null character..), and fix it. Its simple. Theres no reason (if you work at it) you couldnt write a function thats just as secure as cgi.pms. Its all perl.
Yes there is. You're human, you're one human, you won't show anybody your code (and you're admitted newbie, which ain't helping your case). If you want to be taken seriously, you've either got to use accepted methods, or prove yourself by posting code to be examined.
"Using functions to output wellformed html". Right, like h1('text'); is any easier then print "<h1>text</h1>";? Its just as hard to remember to close your parens and so forth as it is to add closing tags, not to mention the fact that not closing your html tags just makes the page look kinda ugly, whereas not closing your parens breaks your script. (you could argue that then the compiler could catch your error, which is a small advantage, but you could easily see and find your error once you via it in a renderer. *shrug* i dont think that its that big of a deal, but ymmv).
Your mileage may not vary. HTML like CGI has a spec, and like CGI, many a browser don't implement it right. You should not rely on either to tell you what's valid (looks good in IE, did you try Netscape? Mozilla? )
Making my own functions to output cookies and parse incoming formdata (of various sorts) also provided a valuable learning oppurtunity, as i got to learn a lot more about how webclients work with headers and submit files in forms and so forth. This is a small benefit, but a benefit none the less, say, if i wanted to go write a cgi program in some other language that doesnt have nice purty functions to do it all for you.
That's still not an excuse for not using (now I know you didn't get paid to write this). It's great to experiment, and learn, and roll your own, but don't expect people to accept it as anything more than your tinkerings for your learning pleasure.
To sum it all up, my "home rolled" cgi-parser may not be the best, fastest, most secure function in the world, but it does exactly what i want and tell it do, it doesnt go around slurping up stdin when i dont want it to.
I'll believe it when I see it. Post the code.

Around the beginning of this post you said "seeing that 'use' is such a favored mantra here, i thought i might introduce a different perspective on the matter" ~ your perspective is that of every cow!bie who didn't want to use CGI, and simply don't apply (learn all you want, but perlfaq is there for a reason, cause it's already been done well).


In reply to Re: A "newbies" thoughts on by Anonymous Monk
in thread A "newbies" thoughts on by BUU

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.