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

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!

Reply via email to