From: Aaron Crane
Date: 13:11 on 27 Jun 2006
Subject: CGI.pm
OK, now I know that CGI.pm's HTML-generating functions are considered mor=
e
than somewhat d=E9class=E9, but I have to maintain an application that ma=
kes
liberal use of them. One of the most persistent sources of niggly and
unpleasant bugs in this application is caused by CGI.pm's insanely hatefu=
l
and broken behaviour.
Allow me to explain. Here's how you generate a hidden field with CGI.pm:
print hidden('field_name', $field_value);
This has the benefit of being simple, comprehensible, and elegant. Sadly=
,
it also has the disadvantage of being wrong.
How's that? Well, suppose we're processing the result of submitting the
form that contains this hidden field, and the $field_value you've just
calculated isn't the same as the one that got submitted. In such a case,
CGI.pm thinks that the best thing to do is to COMPLETELY FUCKING IGNORE w=
hat
you told it, and instead SCRIBBLE OVER YOUR DATA with whatever random cra=
p
it received from the form submission. (I'm not going to labour the point
about inappropriately trusting data received from the internet, but pleas=
e
do be aware of it.)
Of course, you can fix this. Here's how to code defensively against this
retarded API:
print hidden(
-name =3D> 'field_name',
-default =3D> $field_value,
-override =3D> 1,
);
(Just for good measure, note how this simple thing now takes up five time=
s
as much vertical space on my screen to fit into 80 columns, and that scre=
en
space is a non-renewable resource.)
This API is just astoundingly fuckwitted. I can't conceive of any situat=
ion
in which it would be desirable behaviour, and it has caused huge numbers =
of
bugs in the software I maintain. And that's in spite of the fact that I
know about this brokenness -- it's so stupid that it's apparently impossi=
ble
to remember to use the ridiculous workaround.
Hate.
--=20
Aaron Crane
From: Nik Clayton
Date: 14:03 on 27 Jun 2006
Subject: Re: CGI.pm
OK, I know it doesn't lessen the hate, but
Aaron Crane wrote:
> print hidden('field_name', $field_value);
[...]
> print hidden(
> -name => 'field_name',
> -default => $field_value,
> -override => 1,
> );
[...]
> This API is just astoundingly fuckwitted. I can't conceive of any situation
> in which it would be desirable behaviour, and it has caused huge numbers of
> bugs in the software I maintain. And that's in spite of the fact that I
> know about this brokenness -- it's so stupid that it's apparently impossible
> to remember to use the ridiculous workaround.
sub hidden {
return CGI::hidden(-name => $_[0],
-default => $_[1],
-override => 1,
);
}
?
N
From: Hakim Cassimally Date: 14:15 on 27 Jun 2006 Subject: Re: CGI.pm On 27/06/06, Aaron Crane <hateful@xxxxxxxxxx.xx.xx> wrote: > OK, now I know that CGI.pm's HTML-generating functions are considered mor= e > than somewhat d=E9class=E9, The mere existence of these methods is hateful. Why? Because they are documented - now documentation is good of course, but when you grep through CGI's docs to find out details of, for example, how to use the `upload` method, you have to first step through lots of details on creating an upload field that you are never going to use. Hate. osfameron
From: A. Pagaltzis Date: 19:47 on 27 Jun 2006 Subject: Re: CGI.pm * Aaron Crane <hateful@xxxxxxxxxx.xx.xx> [2006-06-27 14:15]: > I can't conceive of any situation in which it would be > desirable behaviour, It's useful if you want to redisplay an improperly filled out form to the user. In that case the values you provide would be merely defaults and CGI.pm would take care of stickiness for you. I've actually found it useful on about two occasions. The fact that there's no way to globally turn off this behaviour is absolutely hateful, however. At first I relied on calling CGI.pm's routines from my TT2 templates to generate my form elements, because that's much nicer than typing out the entire form element HTML every time, particularly for the complex ones like select boxes. Well, it *would* be much nicer -- if the stickiness was easy to turn off. HATE. It would also help if TT2 was at all useful at manipulating data structures, because CGI.pm's routines sometimes have somewhat peculiar preferences. Alas, data structure manipulation in TT2 is about as powerful as in the Bourne shell. Crippled template mini languages: a hate for another day. Aaaaargh. Regards,
From: peter (Peter da Silva)
Date: 20:02 on 27 Jun 2006
Subject: Re: CGI.pm
My Tcl form generator has the same "bug"!
> print hidden('field_name', $field_value);
puts [hidden "field_name" $field_value]
Which is equivalent to:
puts [tag input type hidden name "field_name" value "$field_value"]
Which produces:
<input type=hidden name='field_name' value='$field_value'>
> print hidden(
> -name => 'field_name',
> -default => $field_value,
> -override => 1,
> );
Well, hmmm...
puts [hidden "field_name" $field_value override 1]
==> <input type=hidden name="field_name" value="$field_value" override=1>
Can you write the Perl similarly?
print hidden('field_name', "$field_value", -override => 1);
Or is this really Perl hate?
From: A. Pagaltzis
Date: 20:16 on 27 Jun 2006
Subject: Re: CGI.pm
* Peter da Silva <peter@xxxxxxx.xxx> [2006-06-27 21:05]:
> Well, hmmm...
>
> puts [hidden "field_name" $field_value override 1]
> ==> <input type=hidden name="field_name" value="$field_value" override=1>
>
> Can you write the Perl similarly?
>
> print hidden('field_name', "$field_value", -override => 1);
>
> Or is this really Perl hate?
There's no language-level support for such use. The arrow is just
a special-cased comma -- it doesn't create pairs or anything like
that. (I'm not sure how your example gets parsed as it should,
either.) However, it'd be pretty trivial to offer something very
close to your suggestion, eg.:
print hidden 'field_name', $field_value, { -override => 1 };
CGI.pm doesn't.
Regards,
From: peter (Peter da Silva)
Date: 03:08 on 28 Jun 2006
Subject: Re: CGI.pm
> There's no language-level support for such use. The arrow is just
> a special-cased comma -- it doesn't create pairs or anything like
> that. (I'm not sure how your example gets parsed as it should,
> either.)
It's easy in a language that's a piquant blend of lisp, awk, and grep.
proc input {type name value args} {
eval [list tag input type $type name $name value $value] $args
}
And of course...
proc tag {tag args} {
lappend list $tag
foreach {name value} $args {
if {"$name" == "-flag"} {
lappend list [string toupper $value]
} else {
lappend list [string toupper $name]=[quote_string $value]
}
}
return <[join $list " "]>
}
And to be complete (sorry for the double negative in the first line):
proc quote_string {string} {
if ![string match "*[^a-zA-Z0-9.-]*"] {
return $string
}
if ![string match "*'*" $string] {
return '$string'
}
if ![string match "*\"*" $string] {
return "\"$string\""
}
regsub -all "'" $string "\\'" string
return '$string'
}
Generated at 10:26 on 16 Apr 2008 by mariachi