Randal L. Schwartz wrote:
The thing that CGI.pm does is put in one place everything you need for a
simple web form. And there's an amazing number of applications for
this... putting a "contact us" page on an otherwise static site comes to mind
immediately.
Sure, if you're building a complex shopping cart application, you're gonna
reach for Jifty or Catalyst, or at least roll your own with Template Toolkit
or Mason, and you'd be silly to use either CGI.pm's parsing or HTML generation
in those cases.
You seem to be forgetting the case in the middle - a small dynamic site.
My weapons of choice for that are CGI.pm to parse requests and
Template Toolkit to stuff the relevant content into templates. Frankly,
to use something heavier when I don't have to (and TT is already
somewhat heavy for my tastes) would be silly. And to have a plethora of
little scripts each using CGI.pm to parse requests and to then generate
the appropriate HTML, instead of having *one* script which uses TT would
be, frankly, insane.
But don't throw out the simplicity of CGI.pm's basic task handling: parsing
the incoming parameters (including file upload), and generating sticky forms
and other common HTML elements.
That's two tasks. It should be two modules.
I suppose you could argue that generating <FORM> tags specifically and
all their baggage like <INPUT>s might fall under its remit (they are,
after all, what generates the fancy requests that are CGI's bread and
butter), but generating <H1> tags is most definitely not anything to do
with CGI.
--
David Cantrell | Enforcer, South London Linguistic Massive
All praise the Sun God
For He is a Fun God
Ra Ra Ra!
