Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- standard and OOP together
May 10, 2009, 7:14 pm
rate this thread
works but it's ugly, and I'm going to rewrite it. If I decide to use the OO
interface of CGI.pm such as...
my $q = new CGI;
my $name = $q->param( "name" );
...could I still write the rest of my application in a standard way? I mean
what else would have to change?
Re: standard and OOP together
The CGI.pm docs annoy me by calling the CGI object 'query' and using the
indirect object syntax.
my $cgi = CGI->new;
You need to call methods on the $cgi object thus created.
If you want to enforce the pure OO nature of the $cgi object, you might
want to use CGI::Simple (and move all HTML generation to
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
Re: standard and OOP together
You may or not may be aware that typically Perl allows multiple ways
to do the same thing. Emitting HTML is one of those things that you
can do a number of different ways. I don't use CGI to emit HTML, I
don't like CGI for this purpose, and the following two paragraphs are
an attempt to justify my view. Note: most Perlists will disagree with
the following and find much fault with it, but you need to form your
own opinion. Don't take my word for it, but try it my way just for the
sake of comparison.
specifications and their own validators. The specifications have as
their goal an absolute language standard which user interface agent
writers can rely on. I believe strongly in a strict adherence to the
standards, and that HTML authors should not cater to just one browser,
e.g., IE. In pursuit of this goal, I believe that HTML authors should
begin with hand written HTML (and CSS and JS) code written in a plain
text editor, like vi or notepad, and validating your code. Yes, if you
are in a production environment you will use an automated tool, like
Dreamweaver, but there is no substitute for the skills that
handwriting HTML gives you.
Everything I just said applies to HTML code emitted by Perl scripts.
After all, a CGI script is merely a program that spits out raw HTML,
CSS, and JS. The final judgment (if I may call it that) is the quality
of the HTML produced, not the pretty (or obfuscated) code written by
the programmers. Using CGI.pm tends to separate the programmer from
the HTML, and if you care about the quality of your HTML, you need to
see it as it is and without any intervening automation.
Okay, to modularize your code and avoid the cut-and-paste dance, you
will wind up writing functions to produce your HTML, which you will
call from other functions, until you have several layers, in essence
duplication in another fashion exactly what CGI does. HOWEVER -- it
isn't hard to do, and the bedrock on which you build your program is
STILL hand written HTML, and any time you want to look at it and alter
it, you can do so exactly as if you were hand writing HTML in vi or
notepad. The first time you run your HTML (the product of your CGI
script) through the validator and have it flag 127 errors, you will
understand exactly what I mean. You have an ironclad and direct
correlation between your HTML and your Perl script, and can track the
source of your HTML, CSS, and JS output.
For all its merits, CGI.pm doesn't give you this.
- » FAQ 6.22 What's wrong with using grep in a void context?
- — Next thread in » PERL Discussions
- » FAQ 7.1 Can I get a BNF/yacc/RE for the Perl language?
- — Previous thread in » PERL Discussions