in reply to why use OO nature in CGI?

Well, I think this is actually two questions -- why use CGI to dynamically generate HTML, rather than hard coding your HTML, and second, why use the OO interface to CGI, rather than the function calls.

The OO implementation ismay be faster than the function calls. So, that answers #2. (but you're not using the OO syntax, so let's get to the other part).

Now for the question, why use functions to create everything? I don't know for everyone, but I think part of it is a historical thing -- there was a time when HTML was in flux, and new versions were coming out. The big problem, with the change from HTML 3.2 to HTML 4.0 was that a bunch of tags were deprecated. (which is why there's 4.0 transitional, and 4.0 strict) If you have the extra layer of encapsulation, you can do checking, to make sure that the values are valid, and that you're not using tags that you're not supposed to.

You also have the advantage that Perl will generate syntax errors if you don't have matching parenthesis, rather than needing to check the HTML afterwards. (well, it's still a good idea to validate your HTML).

There is also the advantage that you can remove highly repetitive tasks. Some of the potentially most annoying bits in generating HTML are the putting in selected/checked attributes on form inputs. (loop through, find right item(s), and add the extra code).

So yes, there are times when there are advantages to not hard coding your HTML... but well, I tend to go the hard coded route. It's the way I learned to do things, I prefer having the extra control of exactly what gets sent. I keep meaning to learn some of the various templating modules, but I've never had the downtime to mess with them. (and it'd require the other 3 programmers on the project to learn it as well)

Some people have problems with update inconsistencies when maintaining hard coded HTML (making sure that all of the items in a list are similarly modified), but CSS makes things easier, as do text editors with good find/replace functions.

As for the 'free' scripts, well, some of those have been around since the days of Perl 4... they're not exactly things to strive for. (A few 'popular' ones in particular come to mind... *cough* formmail *cough*) Many times, they're written by someone who's just starting to code, and may not know the best practices, especially because they're trying to make it generic enough for anyone to use.

update: 'is faster' didn't go with the rest of the comments about benchmarking... see below

Replies are listed 'Best First'.
Re^2: why use OO nature in CGI?
by johnnywang (Priest) on May 21, 2005 at 08:35 UTC 
          The OO implementation is faster than the function calls.
    That sounds counter intuitive, can you elaborate? Thanks.
[reply]

      Oops...gotta hate when the top of your message directly conflicts with the bottom of the message.

      I should have said 'may be faster' not 'is faster'. The OO style is less memory intensive. In some situations, especially under mod_perl, the difference can be noticable.

      There is also, as mentioned in the CGI CGI docs, a little bit of overhead when importing the functions into your namespace that will most likely be more apparent when running shorter scripts.

      So basically, although the individual method/function calls may be a little bit slower under OO, the overhead it initialization may strip you of that speed.

      Of course, this goes back to the problem of benchmarks -- someone else's tests may not be representative of your situation, so if you're worried about it, you'd want to run your own tests.

[reply]

In Section Seekers of Perl Wisdom