Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

OOP in CGI

by wink (Scribe)
on Jul 29, 2005 at 07:06 UTC ( #479254=perlquestion: print w/replies, xml ) Need Help??

wink has asked for the wisdom of the Perl Monks concerning the following question:

I've been dipping my feet in the CGI pond lately, creating some web applications for my place of employment and for a non-profit I volunteer for. I have a couple of small questions.

1) Most of the code examples I've seen involve something like $query = new CGI; (or one of its other valid formats). Is there any benefit to doing this as opposed to not using an object? In other words:

use CGI; # And other fun stuff $q = new CGI; print $q->header, $q->start_html(-title=>'Title'), p($q->foo); # etc, etc
As opposed to:
use CGI; # And other fun stuff print header, start_html(-title=>'Title'), p(param "foo"); # etc, etc
Any benefits? Downsides? Places where one would be beneficial over the other?

2) To branch off of #1 and anticipate a possible answer, is it possible to have more than one cgi object, and would there be a purpose for this, such as creating multiple forms with multiple submit buttons? Or is it superfluous in this case?

3) Not really OOP, but still CGI: Is there a way in Perl/CGI to make a popup_menu submit on select? Or will I have to use Javascript event handlers or something similar (of which I have very little knowledge, heh)?

Replies are listed 'Best First'.
Re: OOP in CGI
by neniro (Priest) on Jul 29, 2005 at 07:29 UTC
    I always used CGI.pm the OOP-style cause I dislike to polute my namespace with those exported functions. Others dislike to do all those extra typing for $q->.
    I think it's mostly a question of style, not of functionality.
Re: OOP in CGI
by Tanalis (Curate) on Jul 29, 2005 at 08:26 UTC
    To try and answer your questions ..

    As neniro points out, one of the benefits of using the OO interface for the CGI module is the fact that it doesn't cause namespace pollution. For large applications, that's an obvious advantage; for small applications less so.

    Other benefits would include the potential to use multiple CGI objects, but why would you want to? Submit buttons can have values to distinguish them, which can be read as parameters if you give your buttons names.

    As far as 3 goes, I think you're on your own and stuck with JavaScript. To achieve this, you need the client to perform the submit. As all of your Perl lives server-side, Perl doesn't have the ability to manipulate the client in this way.

      Other benefits would include the potential to use multiple CGI objects, but why would you want to?

      To me, the biggest advantage of using the OO interface is that it's easier to pass the request/response around, and possibly replace the implementation later. Some of the frameworks that run on both mod_perl and CGI do this.

Re: OOP in CGI
by davorg (Chancellor) on Jul 29, 2005 at 08:58 UTC

    Your second example doesn't actually work as you need to import some of the CGI subroutines into your namespace. You can do this by importing only the functions you need:

    use CGI qw(header start_html p param);

    Or by importing pre-defined sets of functions:

    use CGI ':standard';

    As others have pointed out, the problem with this approach is that it can lead to namespace pollution, so it's often important to spend time working out which sets of functions to import. As I almost never use the HTML generation routines from CGI.pm (prefering to create my output with a templating system), I often find myself using:

    use CGI ':cgi';

    As that imports all of the functions related to the CGI protocol. Sometimes I can even just get away with:

    use CGI qw(param header);

    As they are the functions I use most often.

    I never use the OO version. I've never come across a situation where I've needed two CGI objects at the same time.

    And as for your last point, you'll need to use Javascript for that. But your Javascript can, of course, be generated by your CGI program.

    --
    <http://www.dave.org.uk>

    "The first rule of Perl club is you do not talk about Perl club."
    -- Chip Salzenberg

      It was not meant to be a working fragment, merely an example of what I was talking about. :) I usually use

      use CGI qw(:standard);

      for my CGI apps (all two of them that I've made so far). I'm not really familiar with what has been called "namespace polution" but I assume it refers to an abundance of crap all in the namespace that can lead to more memory usage, longer access times, more processor usage, etc.

        "Namespace pollution" is where you end up having more symbols in your symbol table than the ones that you put there yourself. It can make things a bit confusing and the chances of having two symbols with the same name is increased. For example, if you have both use CGI ':standard' and use LWP::Simple in your program (which is a pretty common thing to want to do) then both of these modules try to export a subroutine called "head" into your symbol table. This will potentially lead to the universe exploding.

        --
        <http://www.dave.org.uk>

        "The first rule of Perl club is you do not talk about Perl club."
        -- Chip Salzenberg

      I like davorg's explanation. I also tend to do use CGI qw(param header); and such often, or even fully qualify it all, use CGI (); print CGI::header(...). I've written hundreds of CGIs and I've never once started a CGI with the object interface (though I've coded with it in other hackers' scripts). It's extra typing and unless you actually need to pass an object around, like to a templating system or something (I've never had to because Template::Toolkit has a built-in interface to CGI.pm), it's always struck me as a little pointless and really kind of weird.

Re: OOP in CGI
by jbrugger (Parson) on Jul 29, 2005 at 08:20 UTC
    I use the oo version, i think it's better readable and it fits better in our oo-written application.
    It's easy to pass references to the cgi-object to other objects, easy to maintain etc.
    Drawback of oo-style in Perl is that it IS slower, but then that's relative, most of the time sloppy code or bad algorithms slow your app really down, not the use of oo.

    "We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise." - Larry Wall.
      Drawback of oo-style in Perl is that it IS slower

      But that won't effect your choice of either the OO or functional interface to CGI.pm as even if you're using the functional interface, CGI.pm is actually creating and maintaining a CGI object for you in the background. So the functional interface isn't any faster.

      --
      <http://www.dave.org.uk>

      "The first rule of Perl club is you do not talk about Perl club."
      -- Chip Salzenberg

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://479254]
Approved by jbrugger
Front-paged by tlm
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (3)
As of 2022-09-27 19:47 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    I prefer my indexes to start at:




    Results (124 votes). Check out past polls.

    Notices?