OOP in CGI

[wink]

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)?

[neniro]

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.

[Tanalis]

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.

[Joost]

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.

[davorg]

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.

[wink]

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.

[davorg]

"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.

[Your Mother]

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.

[jbrugger]

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.

[davorg]

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.