> 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. IMHO that is: "most sites".
> My weapons of choice for that are CGI.pm to parse requests and > Template Toolkit to stuff the relevant content into templates. That's why I use CGI::Lite - no fancy HTML, only a lightweight module with themost important features. (Gee, I am emitting WML sometimes!) And let me add this as a side note: http://www.w3.org/CGI/ IMHO a module should do what its name stands for. Surely, when I do something with CGI, I also do HTML generation in 99% of the time. But as the matter of fact, I also use DBI in 99% of the time, so why not put DBI into CGI.pm, too? ;) [...] >> 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. Absolutely. > 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. Also consider that handling the "input part" of CGI is very straightforward. No matter what system/language you use, you basically do the same thing (parse/access GET/POST, the ENV variables, etc.) On the other hand, handling the output is much more dubious - besides setting the content type on some other headers, there are dozens of ways to handle/mangle the content you output. Perl5's CGI.pm provides a way, but that is IMHO just a legacy API Perl6 has nothing to do with. Basically everyone who use CGI.pm use ->param() - but only a few use ->h1(), for example. (IMHO if something beyond CGI input handling must go into CGI.pm, then that is cookie handling - but that's another story.) Just my two cents. - Fagzal
