LPM: Re: CGI.pm and why I don't use it.

Rich Bowen rbowen at rcbowen.com
Sat Aug 14 15:39:20 CDT 1999


Mike Andrews wrote:
...
> Someone mentioned at one point that the CPAN CGI module was evil, but
> didn't go into detail.
> 
> What's evil about it?
...

That was me. I'm not sure if I would go so far as to say that they are
evil. And Lincoln was pleasant enough, although somewhat unwilling to
discuss ideas that did not agree with his.

OK, here's my position and my reasons.

I believe that the code and the UI should be kept separate as much as
possible. This is mostly for practical reasons, but also has to do with
the beauty of the code.

Practical reasons: I have customers. My customers do not know Perl.
Frankly, that's fine with me, because if they did, they would not be my
customers. They do, however, know HTML. I am not good at web site
design. Just look at my web site some time, and you will agree with me.
So I write Perl code, and leave the HTML page design to my customers.
This implies that the two are not the same thing, and I don't have to
know one to do the other. To this end, I have developed my own method of
putting HTML in HTML template files, and the code in Perl files, and
never the twain shall meet. This is of course not possible, because you
have to make some of the HTML pages dynamically. I've used
Text::Template - one of the venerable old CPAN modules - to make HTML
template files, and fill in variables at run time. The people editing
the HTML pages see some weird things in the files that don't look quite
like HTML, and they leave them alone. But they don't ever have to edit
Perl code in order to change how their pages look.

The traditional way (pre CGI.pm, perhaps pre cgi-lib.pl) to do this sort
of thing was to have everything inline in your code.

print "<html>\n";
print "<head><title>Page title</title></head>\n";
etcetera.

While this is ugly and confusing to the end user, they can at least see
where the HTML is, and can figure out how to change it. Putting it in a
"here document" (the print <<End; construct) inproves readability. But
the basic problem is still there. The customer has to edit a Perl file,
and look for HTML in it, in order to change their vlink color. This is
icky.

Along comes CGI.pm and makes things infinitely worse.
Now, instead of putting in my code:
print '<INPUT TYPE="textfield" NAME="State" VALUE="gaseous"
JUSTIFICATION="RIGHT">';

I now do:
   $field = $query->textfield(-name=>'State',
                              -default=>'gaseous',
                              -justification=>'RIGHT');

And somehow, that's better? Ick. Double Ick. Triple Ick. By the way,
that's an actual example from the CGI.pm documentation, so someone
thought that this was a good idea. Now, the customer is completely
unable to edit the appearance of their pages, because not only is it
embeded in Perl code, it looks completely unlike HTML,and they have no
idea what they would need to modify.

So, in conclusion, it would seem to me that CGI.pm is great if you are
writing quick-and-dirty one-off CGI scripts that you will never have to
change, and nobody but yourself will ever have to look at. However, if
you ever intend to deliver a product to a customer, it is evil evil evil
(there, I said it, I feel better) and will guarantee that they will not
come to you for the next project. It makes them feel like an idiot, and
make them think that you are making things unnecessarily complicated.
("I just wanted to change the color of the text right there. Why do I
have to hire a programmer to make that change.")

I know, it was a little lengthy, but it's something that I have thought
a lot about, and since this is what I do to pay my bills, it is
important that I keep my customers happy.

I should say, for the record, that Lincoln did discuss with me the
notion of template-based CGI applications, but he was very dismissive of
the idea, particularly of the idea that I had a different way of doing
things, rather than using PHP, or EmbPerl, or ePerl, or one of the other
existing solutions to this problem. All of those products have the
downside that now, instead of the HTML being in the Perl code, the Perl
code is in the HTML, and you have the same problem all over again.

There is also a prevailing (and very irritating) attitude in the Perl
community that if you don't "use CGI" that you are not a real Perl
programmer. This is unfortunate, because I think that CGI.pm embodies
everything that is wrong with the notion of writing OO code purely for
the sake of writing OO code, and is, as such, a very bad example of how
to write Perl code. It is, however, part of the standard Perl
distribution, and Lincoln is credited (by some) of revolutionalizing the
way that CGI programs are written. Yes, he is a brilliant man and knows
more about Perl than I probably ever will, but I still have to keep my
customers happy, and CGI.pm is not the way to do that.

There, have I been verbose enough?

Rich
-- 
It seems to me as we make our own few circles 'round the sun
We get it backwards and our seven years go by like one 
          --Rush, 'Dog Years' (Test for Echo, 1996)



More information about the Lexington-pm mailing list