Well, I have this weird thing where I tailor the code to a particular app. So I can't give you some always-used snippet. There are times when I want to do more with the input than other times. Hell, I recall one time I didn't even want to do the hex decoding on a part of a query string. But of course, CGI.pm does that automatically, so if I had used it, I would have had to re-encode it. How very efficient.
I have never had a problem with the way I parse CGI data. Not once has it caused anything to happen in my programs that I didn't expect to happen. And I've written plenty of fairly-complicated programs, and none of them use CGI.pm. That is, after all, my job. I might do it differently than CGI.pm (I don't know, I've never read the code for CGI.pm), but of course, There's more than one way to do it.
And if my way of doing it is slow and inefficient, then I'd say Tom owes me an apology for never showing the best way. I spend $35 a piece on those books. You'd think they could tell me something I couldn't learn from the manpages. (In case you hadn't noticed, Chapter 3 of the Camel is just the perlfunc(1) manpage, with a few words changed.)
And that whole "hide the details for fear they'll do it wrong" seems a very Microsoft-like philosophy to me.
I've read all the O'Reilly Perl books. It seems to me you don't start learning how to write good Perl until somewhere around Advanced Perl Programming. Especially since Christianson has a nastly habit of using every module he can find without ever telling you what's going on behind them. For instance, in all the shortcomings of Matt's code, at least he knows how to parse STDIN and the QUERY_STRING for CGI input. Christianson just uses CGI.pm. Does he even know how to parse the data himself? Because he sure doesn't find it necessary ever to detail it in any of the books he co-authored. Talk about bad habits.
If it's Perl you're looking to get into, the Great O'Reilly offers up a number of books, including Learning Perl, Programming Perl, Advanced Perl Programming, the Perl Cookbook, etc. Start out with Learning Perl. Some other posts mention Python, which is also good for CGI, and you can pick up O'Reilly's Learning Python and Programming Python. Be forewarned, though. I've used both for CGI programming. And when I'm using Python (powerful though it is), I find myself longing for the regexps of Perl.
If you'd like an online tutorial, you might want to check out The CGI Resource Index, which is made by the same guy as Matt's Script Archive. Between the tutorials on the Resource Index, looking at the source of Matt's script, and reading the O'Reilly books, you can learn just about anything you want to know about Perl.
Of course, if you get stuck, you can always go to ng's, irc, or your local Perl nut.
I have to agree...somewhat.
on
Interface Zen
·
· Score: 1
Here I am, the tcsh user that hates CGI.pm, and I'm about to agree with Tom Christianson. I never thought I'd see this happen. I agree that the vast majority of keyboards these days suck. And those of us with jobs where our bosses don't know the slightest bit about what we do are stuck with those wretched keyboards. I'm surprised Tom didn't make mention of the keyboards you practically have to punch to type a letter. Sheesh, that spells carpal tunnel after five minutes.
But now, alas, I have to take exception to the comments on emacs. As any emacs user knows, you can define your own macros to do whatever you want. This means that everybody can have exactly the functions they need easiest to access. It's time vi died already.
Slashdot Mirror
Well, I have this weird thing where I tailor the code to a particular app. So I can't give you some always-used snippet. There are times when I want to do more with the input than other times. Hell, I recall one time I didn't even want to do the hex decoding on a part of a query string. But of course, CGI.pm does that automatically, so if I had used it, I would have had to re-encode it. How very efficient.
I have never had a problem with the way I parse CGI data. Not once has it caused anything to happen in my programs that I didn't expect to happen. And I've written plenty of fairly-complicated programs, and none of them use CGI.pm. That is, after all, my job. I might do it differently than CGI.pm (I don't know, I've never read the code for CGI.pm), but of course, There's more than one way to do it.
And if my way of doing it is slow and inefficient, then I'd say Tom owes me an apology for never showing the best way. I spend $35 a piece on those books. You'd think they could tell me something I couldn't learn from the manpages. (In case you hadn't noticed, Chapter 3 of the Camel is just the perlfunc(1) manpage, with a few words changed.)
And that whole "hide the details for fear they'll do it wrong" seems a very Microsoft-like philosophy to me.
I've read all the O'Reilly Perl books. It seems to me you don't start learning how to write good Perl until somewhere around Advanced Perl Programming. Especially since Christianson has a nastly habit of using every module he can find without ever telling you what's going on behind them. For instance, in all the shortcomings of Matt's code, at least he knows how to parse STDIN and the QUERY_STRING for CGI input. Christianson just uses CGI.pm. Does he even know how to parse the data himself? Because he sure doesn't find it necessary ever to detail it in any of the books he co-authored. Talk about bad habits.
No, it's not the best code in the world. But it's a nice starting point. A newbie sure doesn't want to try to read my code.
If it's Perl you're looking to get into, the Great O'Reilly offers up a number of books, including Learning Perl, Programming Perl, Advanced Perl Programming, the Perl Cookbook, etc. Start out with Learning Perl. Some other posts mention Python, which is also good for CGI, and you can pick up O'Reilly's Learning Python and Programming Python. Be forewarned, though. I've used both for CGI programming. And when I'm using Python (powerful though it is), I find myself longing for the regexps of Perl.
If you'd like an online tutorial, you might want to check out The CGI Resource Index, which is made by the same guy as Matt's Script Archive. Between the tutorials on the Resource Index, looking at the source of Matt's script, and reading the O'Reilly books, you can learn just about anything you want to know about Perl.
Of course, if you get stuck, you can always go to ng's, irc, or your local Perl nut.
I agree that the vast majority of keyboards these days suck. And those of us with jobs where our bosses don't know the slightest bit about what we do are stuck with those wretched keyboards. I'm surprised Tom didn't make mention of the keyboards you practically have to punch to type a letter. Sheesh, that spells carpal tunnel after five minutes.
But now, alas, I have to take exception to the comments on emacs. As any emacs user knows, you can define your own macros to do whatever you want. This means that everybody can have exactly the functions they need easiest to access. It's time vi died already.