http://www.perlmonks.org?node_id=279770


in reply to CGI versus CGI::* modules

I wrote a little about this here.

IMHO, the entire community would benifit if CGI.pm were left behind. Somehow, I've gotten into the habit of putting a use CGI qw(:standard); at the top of every CGI I write, and I really need to get that changed to CGI::Simple or something else. I hardly ever use anything from CGI.pm besides param() (though I really ought to use header(), too), and it seems wasteful to load up that beast of a module just for one subroutine.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated

Replies are listed 'Best First'.
•Re: Re: CGI versus CGI::* modules
by merlyn (Sage) on Jul 31, 2003 at 20:48 UTC
    Well, I disagree. CGI.pm is a great first step away from the hand-rolled solutions, and it's ubiquitous, being a core module.

    It also handles cookies, sticky fields, and XHTML generation quite nicely.

    I'm not sure what you mean by "beast of a module", since it's also "self-loaded", only compiling the parts of itself that you ask for, so it's really the same as a dynamically readjusting module that has exactly what you want. What more could you ask for?

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

      I agree that CGI.pm is great for getting away from hand-rolled solutions. It may not be perfect, but you could do far, far worse.

      Handling cookies is nice, but there again, other modules exist that handle that specifically. Sticky fields and XHTML aren't a concern for me, because I use templates extensiviely for any non-trivial CGI.

      That's interesting about the dynamic loading, I didn't know about that.

      ----
      I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
      -- Schemer

      Note: All code is untested, unless otherwise stated