[prev] [thread] [next] [lurker] [Date index for 2006/06/27]
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
Generated at 21:00 on 05 Jul 2006 by mariachi 0.52