OO CGI vs. function-oriented

[krujos]

I should start this by saying my experence with perl/CGI is pretty limited. I am trying to understand the advantages of using the object oriented model when using cgi. Are there any clear advantages over using the function-orented approch? After reading the manual, tutorials and perldocs for CGI.pm I cant find the advantage. Does it give access to more functions? When using OO it seems like the code is a little more cluttered, and that makes understanding it that much harder. Please give me some insight to the advantages of using OO for this.

[n3dst4]

If function-oriented programming is a screwdriver, OO is a bench drill.

Do you have a big, heavy lump of problem that needs some serious torque, or do you just need to screw someone's comments onto an email? What OO gives you is organisational power, but it comes with a price: time. If you're writing a major online application (like Perl Monks!) try sticking to OO. As you code grows, you'll still be able to see the over-all shape of it. Better yet, people maintaining your code will be able to get a handle on it. If it's a standalone scriptlet, OO will double the size of your code for no reason. Choosing OO CGI modules will help you keep the rest of your code OO.

Interestingly(1), I've been thinking about this very subject today. I've started rewriting our office intranet, which started out as just a support ticketing system, but has grown to include project management, document handling, DNS database administration, an address book, a skinnable interface and optional sidebar nodelets. At the moment, it's a mixture of some loosely-integrated PHP, a few Perl CGI scripts, some ColdFusion and some magic. Some applications have their own entire databases and user lists. Some reside on completely different servers. What I've started doing today(2) is breaking all the managed things into classes, and defining their capabilities in a class definition. The request procedure for the new single-application-multiple-functions intranet will involve one handler script setting up global objects representing the datasource, the logged-in user and a few other things, then calling a top-level page template object, which will, in turn, call the objects required to draw the page. I also, along the way, define an object API to easily extend the intranet's functionality. Thus, the nightmarish task become manageable.

Sorry, I've rambled. What was your question? :-)

(1): Or not.
(2): Working on a Sunday. Tsk.

[thraxil]

probably one of the easiest to understand reasons for using an OO interface over the function oriented one is to prevent namespace pollution.

if you're using the function oriented interface, you have to be careful that nowhere in your code do you have a subroutine named 'param', or 'upload', or 'header' or any of the other functions that CGI defines. so first of all, you have to be familiar enough with the CGI module to know the full list of functions it exports, then you have to be careful to avoid them in your own code, then you have to be careful that any other modules you use don't export functions with those names. the last part is the real kicker, especially since it makes it more difficult to add modules in the future.

on the other hand, if you're using the OO interface, you can just do

my $cgi = new CGI();
my $foo = $cgi->param('foo');
print $cgi->header();
&param($foo);
&header($foo);
...

sub param {
  ...
}

sub header {
  ...
}

and know that your param and header subs will never get confused with CGI's.

personally, i find that using the OO interfaces to modules looks cleaner and easier to read, as long as things are named well. you always have the '$cgi->' there to give you a hint that the function being called is something to do with CGI.

anders pearson

[merlyn]

Although the perldoc for CGI.pm shows the OO interface, when you look at anything else Lincoln Stein has written about it, he shows the functional interface instead.

When I bugged him about it last week on the boat, he said something like "Yeah, that whole doc needs to be rewritten, but I'm too busy at the moment".

I take that to mean that Lincoln himself prefers the functional interface for small to medium programs, and simply has the OO interface in the docs because of inertia.

-- Randal L. Schwartz, Perl hacker

[shotgunefx]

Even if you are using the functional methods, you are really still using an object, $CGI::Q.

For most applications with CGI.pm, I use the functional. It keeps it alot cleaner and has never been a problem for myself. You can still use the object oriented methods when you want.

Update
I just want to add, that I use the html generation for all of my applications and even with the functional interface, advanced layouts are really ugly. (I like keeping my code and presentation together for most big apps as ours tend to have a few users at a time and upward of 20 different screens and we can subclass CGI to enforce what we send and recieve as we know what we output. Less fragile for our applications. )Adding lots of $q-> doesn't help make it any easier to understand.

-Lee

"To be civilized is to deny one's nature."

[tilly]

Keeping content and presentation together for big projects is generally a serious design mistake, and the ugliness of the advanced layouts should be a tip-off to you that you are being bitten by it.

See Re: Re: Re: Re: Code Critique for a basic list of reasons why it is a good idea to separate content from presentation. (And if you read my response later in the same thread you will see that I don't merely advocate templating as a religious persuasion.)

[shotgunefx]

One of the modules that we are using, which I hope to get on CPAN someday (can't right now cause of work restrictions.) is a Persistance mechanism for CGI. Basically a state machine. It's for heavyweight apps. (Some 30 or 40 screens.)

The nice thing about tieing the form generation to the code is that because it generates all the forms, we know what parameters to expect and what they should contain, even how many values they can provide all transparently. (Even files), There is no form validation at all as it's all handled through the object. If the user doesn't supply something, it rolls back state automatically and tells them what they need to do. (We might eventually build a templating system around it which would give us the benefits of both, just not a big priority right now.)

You pretty much can't break it. Usually the only thing required to use this on a script that uses CGI is to change the use statement and the call to new and you gain most of the benefits.

We use a parser to generate the form code from html which let's us leverage non-programmers for the UI.

These won't be used by a lot of people so the extra weight is well worth the trade for simplicity and speed in development.

For many applications, I would agree with you but I think sometimes it makes a lot of sense. Plus if we have to migrate it to a new machine it's a matter of setting up one module and one script and where done.

-Lee

"To be civilized is to deny one's nature."