The difference is, the efficiency and data structure CGI.pm returns. Mine came to
I think 72
times faster when not uploading images, and 2.5 times faster when uploading images.
I'm not saying
CGI.pm is written poorly or anything, I am saying that it is a little bit bloated and
has a lot of
functionality that is not needed (especially if the only thing you are doing with it
is receiving
input).
Well personally, I've always used
print "Content-type:text/html\n\n";
but somebody told me this was not the spec, so I read through the spec and looked up
how CGI.pm was
doing it and what I found was
${CRLF}${CRLF}
as the \n\n replacement. I of coarse should have looked a little higher where they
defined $CRLF,
or at least tested what I had read before posting it, but oh well. From here on out,
I'll stick
with what I've known to work instead.
Like I've said before, it doesn't make much sense to make a wrapper for CGI.pm so
that I can
have things the way I want them, because this is doubling the work necessary. I'm not
making my lib
to prove superior, or to say anything like mine is better. I have simply found a very
positive
solution for me (quick and in a structure that works well for me). If others like my
solution, and
it works well for them too, more power to them. I will post mine on CPAN, if nobody
else in the
world feels it is a good solution for them, that's just fine with me. If people like
my solution,
but have a few suggestions of how to improve it, I welcome that.
One thing I am open to after posting my lib to CPAN is suggestions. I'm not
exactly close
minded here, I'm just the type of person who if I'm not perfectly happy with the way
something works
(whether programming or in the real world), I determine whether I can fix it, if I can
I do.
Because this lib puts the received values in a structure that I like to work with, in
my mind it
fixes things.
David
----- Original Message -----
From: "Todd Wade" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 26, 2002 11:12 PM
Subject: CGI.pm v/s roll-your-own [WAS:] Displaying Problems
<[EMAIL PROTECTED]> wrote in message
008d01c21c73$aa978a30$d381f6cc@david">news:008d01c21c73$aa978a30$d381f6cc@david...
...... snip
> I'm sure I'll get lots of hate mail from CGI.pm die hard's, but my
other choice is to just not
Not trying to post hate mail, just reasoning on the subject.
> post this at all. What I hope for is several people telling me how to
make it slightly more
> efficient or compatible with other OS's (you see I've only had opportunity
to test it on Linux and
> Win2000, though I've been testing it on Linux for about 2 1/2 years).
Lincoln Stein (the original author of CGI.pm) already has (lots of) people
doing this for him, and his module has been maintained for around 10 years.
Its been tested on scores of OS's. Ive read four of his books. There is a
book dedicated to CGI.pm. My point is his module has been rigorously
debugged and you are just now here asking people for help debugging yours.
> Its pretty hard to make it more simple than:
> use Form;
> my %input = Form();
>
But something else has already made it that easy.
Im not knocking your module. Im just explaining why people like us trust
people like Lincoln Stein's module over yours. For example, Ive seen alot of
hand rolled CGI parameter parsers, most of them have a line that says:
@pairs = split(/&/, $ENV{QUERY_STRING}); # WRONG!!!!!!
This works when the user agent uses an & as a delimeter, but some user
agents use ; (a semicolon) which is perfectly valid. program chokes. Then
people are in the newsgroups trying to get others to help track down a very,
VERY difficult-to-track bug. But at the end of the post they say, "I dont
want to use CGI.pm!" Floors me. Really floors me. And this is just one of
several examples I've seen.
So I know, when I say:
print $q->header();
Its going to get it right.
BTW, I find the source to CGI.pm very easy to read and makes alot of sence.
Ive seen suggestions from you in this thread that are either wrong or wont
even work. (What does this do-> print "Content-type:
text/html${CRLF}${CRLF}";) Which tells us again Mr. Stein has a thorough
understanding of the HTTP protocol, while you stll have a little to learn.
Again, this is NOT a flame. I suggest accepting the constructive criticism
professionally.
Todd W.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
