Re: Why is parsing your own form data a bad idea?

drieux Fri, 07 Nov 2003 16:30:11 -0800


On Friday, Nov 7, 2003, at 11:42 US/Pacific, R. Joseph Newton wrote:
[..]

Perl has many APIs, for many purposes. I personally don't like using CGI.pm for generating Web conent. This I do by hand, checking the generated html source and its rendered appearance throughout the process, because I think that the appearance of both is important.


you will forgive me if I truncate the content here
to help refocus the discussion. I am also, well pleasantly
amused that we both agree, mostly-ish, that the CGI.pm
module has 'upside' and 'downside' issues.

p0: since this is a beginning list, it is probably best
to re-iterate that it is a great place to start! both
in terms of using the model to begin with for 'creating'
HTML content, and stepping into the Abyss of CGI.

p1: at which point one then needs to start asking the
sort of question like, "so why exactly do I want to
use this module over that module" - since there are
some really fun modules out there, including some
serious folks working on a Form Application Framework
that mostly simplifies the process, somewhat.

I strongly agree with the design goal of XML that source
should be human-readable and clear.  I would add ergonomically
sensible to the standards.


p2: Ironically of course PCDATA is also, well, an xml application,
hence 'raw ascii' also complies.... 8-)

Parsing form data, the subject of the OP, is a different matter. CGI does a very solid job of abstracting the details of delivery format, and rendering the parameters to the application. What more do you need from a CGI module? For other purposes, you can use other modules.

[..]

p3: The OP's question, if I am correct,
cf: <http://nntp.x.perl.org/group/perl.beginners/54932>

also specifically addressed the kvetch in the FAQ, which asserted:

        <<"You use a standard module, probably CGI.pm. Under no
                circumstances should you attempt to do so by hand!">>

and hence his step off to the horrors of what would be badly
named hashes .... eg %GET and %POST - garish! yech!! tasteless
naming schema! ptewee... That we should kudgel dan for! since it is
such an affront to 'good taste'.

but structurally his idea is Kosher in challenging the 'recieved'
wisdom of the Omniscient Perl Faq! Since once one steps out there
and does the first Nightmare of something like:
        ...
        my $request = $ENV{'REQUEST_METHOD'};
        ...
        if( defined($request) && $request =~ m/^POST|GET|HEAD$/)
        {
                my $queryString = ($request eq 'POST' )?
                        <STDIN> : $ENV{'QUERY_STRING'};
        
                my $qs = unpack_query_string($queryString);
        
                $page = ( ($qs && defined($qs->{dir})))?
                         do_it($qs): make_localPage() ;
        }else{
                ...
                # normally I send UGLY message to browser about DISALLOWED
        }

since of course POST and GET will pass the information in different
manner, and some Whiney Implementations of Browsers will want to
know that they could 'HEAD' the cgi - but of course he will want
to make emotional commitments about the rest of the basic syntax
and semantics that can be done with CGI on the else side of the
branch... { assuming that he doesn't CHEAT and create his own
set of them for 'not merely woofing HTML' forms of CGI.... }

So they start picking and grinning with their own 'query string unpacker' like say something a la: #------------------------ # sub unpack_query_string { my ($qstring) = @_; return unless $qstring; my $queryHash; chomp($qstring); my @args = split(/&/, $qstring); foreach my $thing ( @args) { my ($k, $v) = split(/=/, $thing); next unless(defined($v) && $v ne ''); # double coverage here, requires var=val structure $k =~ s/\+/ /g; $k =~ s/%(..)/pack("c",hex($1))/ge; $v =~ s/\+/ /g; $v =~ s/%(..)/pack("c",hex($1))/ge; $v =~ s/\s+$//; $v =~ s/^\s+//; $queryHash->{$k} = $v; } $queryHash; } # end of unpack_query_string

and yes, yes, yes, that way does lead to the problems about
how to make the right types of choices should a form want
to pass back a list var1=bob&var1=sally&var1=orthodoxy, but
that too will be something that they will think about and
implement a unpack_query_string_with_dupes() that they will
use for the times when they notice

        Friggolating, what was I thinking about in allowing the
                Primate to Select Multiple things, OxygenSuckingCarbonBasedLifeForms
                        that merely Poke, Poke at the Pretty GUI interface....

I mean we all make that mistake more than a few times in the process...

        "lovely web application, but we want you to add just this
                little check box option on...."

But do we SHOOT the marketing DROIDS at that tyme? Do We Pour
coffee down their fronts and watch their little circuits fry....
{ oh, sorry, wrong rant. }

Clearly if we allow beginners to question the Recieved Truths,
and start wandering off the Res, what next???

I mean how are we going to keep them on the farm, when they figure
out that h2xs will help them spin up their own modules so that they
can hack around and decide to be orthodox or Apostate!
{ cf 'perldoc h2xs' - but only if you remember to do it right... }

and the next thing you know, dogs and cats will be living together...

OK so we should make them sit down Purchase the objects,References and modules book that Randall just put out cf <http://www.oreilly.com/catalog/lrnperlorm/> so as to get a leg up on that long term problem of software development and maintenance that comes with having an interesting idea and trying to maintain it...

and maybe oblige them to learn some respect for their elders....

Or maybe we help them

a. ask interesting and emotionally traumatizing questions b. remember that we too have done that c. note that 'hard and fast rules' are so until you have a really good reason to go off the reservation, which we will want to support, as long as they do it right, and especially if their wacko idea is something that they should post to the CPAN....

But of course, baring the details, we mostly agree.

Today it's 'just a web page' - and tomorrow they are over reading the P5EE discussions about freaking web-technologies and the "why not do it in Perl rather than Java, since my FrikaZoid2000 has an implementation of Perl but no JVM..." and then the Apocalypse Arrives...

ciao
drieux

---

ps: props for the line

"Just because the marketing-slime of the telecom industry latch onto the work of serious thinkers and try to bathe in the aura of illusory "progress", does that mean we should adjust to accomodate them? Not unless they [ie the telecoms and the multinational belly-crawlers who finance them] are paying me."

way so .sig fodder!


--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Why is parsing your own form data a bad idea?

Reply via email to