Just wanted to say two things:
1) These are my sentiments exactly - I've only been on this list for a few
days and I've seen a lot of religous responses. However, as a newbie, I
don't mind extra flack as long as I can get to the meat of the matter (ie:
sometimes when you guru's respond, you make some assumptions of our
knowledge [ie: using mod_perl for directory access/password protection] - I
don't mind doing research, as long as you'll tell me where to go [uhh ...
hope I'm not opening myself up there ;)] to find more information ... code
examples are great, too!).
2) I'd HIGHLY recommend buying the Llama book (Learning Perl) - it sounds
like you got a bad first book from O'Reilly, but I LOVE the Llama book and
that's how I got started, myself.
Jason
----- Original Message -----
From: "GPG" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, July 09, 2001 11:14 PM
Subject: Re: Use CGI.pm or Parse it in the script?
> Curtis,
>
> *sigh* Thanks for the information.
>
> I'll tell you, my site is all flash, and I wanted to make it a bit more
> interesting by having some dynamic data on the site facilitated by CGI.
> Trying to find a -simple- resource for learning Perl has been a real
> struggle. Perl seems more like a religion than a programming language,
and
> there seems to be no way to get what I need and 'plug it in'.
>
> I am more an artist than a programmer, so I'm willing to live with
> inefficiencies in my code, as long as I get the darn things working. It
> seems, though, that whenever I try to find an answer to a simple question,
I
> have to wade through a lot of extraneous information.
>
> It's great that people have a passion for a language, but sometimes I
think
> they tend to alienate the newbies and the casual user.
>
> I just bought the latest edition of Elizabeth Castro's book, and it's
great.
> It tells me exactly how to get specific things done with Perl. I had
first
> bought O'Reilly's CGI programming with Perl, and I took it back because it
> tought virtually no Perl. If I were to stick with O'Reilly, I would have
to
> by a small library worth of books to get some relatively simple things
done.
>
> Thanks for the info, and the pointers.. actually, that code was snipped
from
> another script. I'm learning Perl the same way I learned HTML...but:
>
> $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
>
> Means absolutely nothing to me... but the durn script works! So I'm
happy.
> :)
>
> Maybe next time I'll switch to PHP.
>
> -g
>
> Visit Zanpo, Virtual City
> http://www.zanpo.com
>
>
>
> ----- Original Message -----
> From: Curtis Poe <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, July 09, 2001 4:50 PM
> Subject: Re: Use CGI.pm or Parse it in the script?
>
>
> > --- "G.P.Gaudreault" <[EMAIL PROTECTED]> wrote:
> > > All,
> > >
> > > Which is faster, using the CGI.pm param function to get form input, or
> parsing out the hash
> > > within my script? I've got a script that currently uses a lot of
system
> resources, and I'm
> > > looking for ways to optimize it.
> >
> > [snip]
> >
> > > Is it faster to run this, or use CGI.pm and call param()?
> > >
> > > -GPG
> >
> > Your routine is faster. It's also chock full o'bugs. For a good
> discussion as to why, check out
> > http://www.easystreet.com/~ovid/cgi_course/lesson_two/lesson_two.html.
> >
> > Ironically, earlier today I asked someone to parse their form-handling
> code stating that I would
> > find at least 5 bugs. The person replied that s?he hadn't really
written
> a form-handling routine
> > but a form *validating* routine. Silly me, not seeing the context.
Now,
> you come along with your
> > form-handling routine and I just happen to have my gun loaded, so please
> don't take any of the
> > following personally :)
> >
> > Your routine has a variety of issues, including some novel ones that I
> haven't stumbled across
> > before. All comments will refer to the line of code following them. I
am
> not trying to be cruel,
> > this is just another example of why "rolling your own" is usually a bad
> idea.
> >
> > ######################################################################
> > sub getform
> > # Looks like we're not using strict! Need to declare variables with
> 'my'.
> > $buffer = "";
> >
> > # Doesn't allow for GET requests (or HEAD or a variety of others,
but
> we rarely
> > # encounter those in CGI scripts.
> > # There is no test to see if the read() is successful
> > read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
> >
> > # Doesn't allow for an alternate delimiter. The semicolon (;) is
> supposed to be the
> > # new delimiter and systems are slowly moving towards that. Those
> will break with this
> > # code.
> > @pairs=split(/&/,$buffer);
> >
> > foreach $pair (@pairs) {
> > @a = split(/=/,$pair);
> > $name=$a[0];
> > $value=$a[1];
> >
> > # why didn't we do this with $name?
> > $value =~ s/\+/ /g;
> >
> > # why didn't we do this with $name?
> > $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
> >
> > # why are we throwing away data that we might need in the
future?
> > # what if you need data from a textarea tag?
> > $value =~ s/[\r\n]//g;
> >
> > # why not add them to the %form hash?
> > push (@data,$name);
> > push (@data,$value);
> > }
> > # Oops! We just lost all multiple values.
> > %form=@data;
> >
> > # returning a reference to the hash instead of the hash is probably
> faster,
> > # especially if you're working with a large hash.
> > %form;
> > }
> > ######################################################################
> >
> > Let us know if you have any more questions.
> >
> > Cheers,
> > Curtis Poe
> >
> > =====
> > Senior Programmer
> > Onsite! Technology (http://www.onsitetech.com/)
> > "Ovid" on http://www.perlmonks.org/
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Get personalized email addresses from Yahoo! Mail
> > http://personal.mail.yahoo.com/
>
