in reply to CGI versus CGI::* modules

I think that the biggest plus in favour of CGI is wide distribution and user base. It is pretty rare to find a perl installation that doesn't have it, and of course it is the de facto standard for CGI scripts.

Something like CGI::Simple means a good chance that the user has to install it. This is something you need to consider, particularly if everybody starts using their favorite CGI::* module instead of the standard CGI.

I might consider using one script over another if that script used modules I already have, rather than ones I need to install. (And of course, some don't know how to install modules, or don't have access to do so.)

This is not to say that CGI is the best or only solution, but these are things that I think also merit consideration when deciding what module to use.

</ajdelore>

Replies are listed 'Best First'.
Re: CGI versus CGI::* modules
by jonadab (Parson) on Aug 02, 2003 at 04:12 UTC
    Something like CGI::Simple means a good chance that the user has to install it.

    Depending on what you're doing, that may not be a real issue, since you may by virtue of your requirements already need some non-core modules. For example, Bugzilla, no matter how it was done, could not have gotten away without at least one non-core DBD module, and practically it really had to have a datetime module as well. (I don't happen to know which one it uses.) If your project has this sort of situation, you can use any module you want that's on CPAN, _especially_ if it's pure Perl, and then create a Bundle:: module that pulls in every module you use. The user doesn't even have to _care_ what individual modules you've used; they just install Bundle::Whatever like your install instructions say, and off they go.

    OTOH, if you're only using one non-core module and you can easily avoid it by using a core module instead, by all means, do that.

    As far as CGI.pm, I got so disgusted with it after seeing the output of some scripts that use it, that I have never even contemplated pondering the possibility of considering ever using it myself. Maybe the authors of the scripts in question used CGI.pm wrongly, and maybe I'm doing CGI.pm an injustice, but CGI is such a simple thing, it wasn't at all difficult to roll my own solution, which handles everything I need (yes, including cookies, which are stored in a MySQL db; my login/logout box is a self-contained function so the user can log in or out from any page that contains it.), runs in taint mode (using Taint to taint the input after parsing it into key/value pairs), returns the form input as a nice tidy hashref, and produces nicely formatted human-readable output that validates. I thought about distributing it, but there are so many implementations already for this... probably because it's such an easy problem. CGI was designed to be easy to implement. 

    $;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/

    [download]
[reply]
[d/l]
      CGI was designed to be easy to implement.

      So was HTML.

      How does your hand-rolled implementation handle P3P cookies? While you're adding support for those, have you considered CGI::Pretty?

[reply]
        How does your hand-rolled implementation handle P3P cookies?

        Considering that no browser I know about requires P3P by default, and that P3P is basically a placebo, I never saw the point. 

        $;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/

        [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom