Re: CGI.pm for HTML output?
by dws (Chancellor) on Mar 08, 2002 at 22:27 UTC
|
is there any compelling reason for me to go back through and change all of my working HTML heredocs to their CGI.pm equivalents?
Consider the opportunity cost of your time. If what you have works and is maintainable, doing a retrofit probably adds no value. The time could probably be put to better use elsewhere.
| [reply] [Watch: Dir/Any] |
Re: CGI.pm for HTML output?
by perrin (Chancellor) on Mar 08, 2002 at 22:30 UTC
|
No, it's not a big deal. It's usually better to use templates though. You might look at my article on the subject if you want more details. | [reply] [Watch: Dir/Any] |
|
Stick your HTML into CGI.pm when you already have good HTML?
Just like teenage suicide: "Don't do it!"
-mr.dunstan
| [reply] [Watch: Dir/Any] |
|
Uh, yeah, that's what I said. Or are you just agreeing with me?
| [reply] [Watch: Dir/Any] |
|
Re: CGI.pm for HTML output?
by erikharrison (Deacon) on Mar 09, 2002 at 02:38 UTC
|
It has been agreed that there is one, and only one, issue which perfectly splits the Perl community down the middle 50-50: CGI.pm and the HTML methods. Half like 'em, half don't.
I find that I prefer letting CGI.pm handle frms, but at the same time, really don't like the HTML methods. And you really shouldn't mix th two, unless you want to blow a synapse (although letting CGI.pm produce the header and handling the rest your self is not so bad).
A good discussion of the routines came up while discussing CGI.pm's would be successor, on over at RFC CGI.pm refactoring. You might want to check it out.
Cheers,
Erik
| [reply] [Watch: Dir/Any] |
|
Trying... to... resist... jumping into... the fray. (Too late).
I would definitely not use the CGI methods of generating HTML for the entire page/site, for the reasons tilly and others give. But I do think that there is one place where CGI.pm's HTML generation functions shine: any kind of input form.
My rationale? CGI.pm form fields are "sticky". This means that if you have to print out the form a second time (e.g. to have a user correct some invalid input), it is reincarnated with all the input from the first pass. Automatically. So you don't have to regenerate the form worrying about substituting any default form values with the valid input from the first submission, CGI.pm takes care of that. And it's easy to delete any form params that happen to be invalid for your program.
This is just my opinion, and others will surely disagree, but I find the HTML generation method invaluable for this reason.
..Guv
| [reply] [Watch: Dir/Any] [d/l] |
|
Um, the split doesn't seem to be very much 50/50 from what
I see.
I am not sure that I have ever met a good Perl programmer
who seriously advocated using the HTML methods for producing
a complex website. For small tools, one-off scripts and the
like, sure. But it doesn't scale as an approach.
| [reply] [Watch: Dir/Any] |
|
While for general purposes I would agree, but I do consider myself I good (not great) perl programmer
and I've found one really nice use.
We have our own persitance module at work based on CGI. Hopefully it will get released to CPAN eventually.
It's used for heavy weight applications. Some of them have 30 different screens. We use the HTML
shortcuts because by doing so, the module always knows exactly what next states are possible and
what fields should be coming in, what values they are allowed to contain and depending on what type
of fields (<select>s for instance) what values they can have and how many. It also handles
the filefields. You can upload a file input and ten screens later still access them as though
they were in the current submission.
All of this is moved to the module layer. You dont' have to do any of the validation at all. It's all
done for you.
print "INT -100 < 31 ",textfield(-name=>'int',-validate=>{
-datatype=>'INT',
-min=>'-100',
-max=>'31',
-required=>1
}
),br();
Now when the user submits, the module knows that it needs a a parameter called
int with a value between -100 and 31. If it doesn't get it, it rolls back
to the previous screen with an error message "You need to enter an integer
between -100 and 31" automatically generated and the offending field marked visually.
Of course, generating the actually code for a complex layout is a huge pain which is
why we have a custom parser that takes an HTML page and translates it to CGI.pm syntax.
Now this type of solutions isn't for everything. (Lot's of overhead) but for a complex app
it certainly can outweigh the cons.
For a simple app, this would be like lighting a cigarette with a blowtorch but unifying the input and output does offer some interesting possiblities.
My two cents anyway.
-Lee
"To be civilized is to deny one's nature." | [reply] [Watch: Dir/Any] [d/l] |
|
|
I find that I prefer letting CGI.pm handle frms, but at the same time, really don't like the HTML methods.
I also like it for tables, especially, and here really is one nifty thing, using array refs.
print table(Tr(td(\@some_data)));
This construction is really handy for formating data pulled out of a SQL database using DBI.
| [reply] [Watch: Dir/Any] [d/l] |
Re: CGI.pm for HTML output?
by Michalis (Pilgrim) on Mar 08, 2002 at 22:35 UTC
|
I don't understand the "heredocs" (some module/command I don't know or an idiom I'm unaware of as I'm not American?) but I'll tell you what I do.
I usually do all the processing in the cgi-script and then use HTMLTP (slightly modified to fit my needs) in order to send all the variables I need (and have generated) from the script to a template web page.
That web page usually consists of three or four distinct pages. One or two with the header and LOTS of layout information, the body page that handles the bare presentation of the info and the footer.
The header(s) and the footer are simple pages that get included in the "body" page, and as such I completely seperate my coding from my layout.
I find that way of working EXTREMELY time saving, plus it gives me the opportunity to handle my pages to a web-designer / graphic-artist and not have him mess with my actual info at all :-)
HTMLTP is a Templating module, and i definitely know that there must be a couple more doing the same thing (more or less) out there.
Hope I helped a little bit
Michalis
| [reply] [Watch: Dir/Any] |
|
In this case, I'm both programmer and designer :)... Templating is a tempting idea, and I've used pseudo-templating for projects in the past.. I'll have to look into these suggestions of templating systems..
| [reply] [Watch: Dir/Any] |
|
Well, I was both programmer and designer, but one day I found:
a) A much better designer than me :-)
b) Money to pay him
c) Many projects that I had to work on, thus limiting my time
So, I decided to dump designing and go on with coding (which is what I like best :-)
That was the time that I realised that templating saved my BIG money (one of my projects wasn't templated.. Believe me, it was the last one I created that way).
Anyway, good luck whichever your choice is.
| [reply] [Watch: Dir/Any] |
|
We had a lot of discussion of the benefits of various templating modules in this thread. HTH jg _____________________________________________________ It's not my tree.
| [reply] [Watch: Dir/Any] [d/l] |
|
| [reply] [Watch: Dir/Any] |
|
Thanks for the link and the info.
It is, really, extremely useful (though I think not for advanced web programming :-)
Actually, I was aware of the method, but I didn't know its name.
Michalis
| [reply] [Watch: Dir/Any] |
Re: CGI.pm for HTML output?
by Sinister (Friar) on Mar 08, 2002 at 22:55 UTC
|
To keep stuff maintainable by not-perl'ers, you could place your heredocs outside of your code and touch nothing else. Unless of course you really badly want to use all the nifty CGI routines.
er formait hyarya.
"Field experience is something you don't
get until just after you need it."
| [reply] [Watch: Dir/Any] |
Re: CGI.pm for HTML output?
by shotgunefx (Parson) on Mar 08, 2002 at 23:05 UTC
|
Not at all. The only compelling reasone for me is that if I want to "hook" form and parameter generation (output), I can override the functions I want or subclass CGI.
-Lee
"To be civilized is to deny one's nature." | [reply] [Watch: Dir/Any] |
Re: CGI.pm for HTML output?
by gt8073a (Hermit) on Mar 09, 2002 at 10:09 UTC
|
Write a complicated web page three diffeent ways. Use CGI for one version, heredocs for another, and any of the templating modules for the third. Wait a week, or two, and go back to make modifications. Better yet, ask someone else to make some changes.
I will never be paid enough to cover my frustration when trying to talk someone through a "minor, 2 minute tweak" of CGI's HTML methods again.
Will perl for money
JJ Knitis
(901) 756-7693
gt8073a@industrialmusic.com
| [reply] [Watch: Dir/Any] |
Re: CGI.pm for HTML output?
by cayenne (Scribe) on Mar 08, 2002 at 22:38 UTC
|
It's really just for input that people do present that as the only good answer. For output it's just one good solution (that I happen to like, particularly after having used it for a bit.) | [reply] [Watch: Dir/Any] |
Re: CGI.pm for HTML output?
by Jules_Verne (Novice) on Mar 10, 2002 at 03:06 UTC
|
As others have said, this topic has been beaten to death, but allow me to give a positive vote for CGI.pm HTML generation methods. If you're in a hurry (aren't we all?), then go with heredocs, but once you learn how to use CGI.pm for HTML generation you will find that it is much faster (unless, of course, you are just cutting & pasting your HTML from another document). I like the fact that CGI.pm always generates a closing end tag for container tags. I have never used CGI.pm for a big HTML project, but I can imagine that its HTML generation would be a welcomed standard in a sea of HTML mess. | [reply] [Watch: Dir/Any] |
Re: CGI.pm for HTML output?
by Trimbach (Curate) on Mar 09, 2002 at 12:57 UTC
|
| [reply] [Watch: Dir/Any] |
Re: CGI.pm for HTML output?
by Stegalex (Chaplain) on Mar 09, 2002 at 15:31 UTC
|
If it aint broke, don't fix it. I like chicken. | [reply] [Watch: Dir/Any] |
|
my $itaintbroke;
dontfixit if ($itaintbroke);
sub dontfixit {
}
print "I like chicken.\n";
| [reply] [Watch: Dir/Any] [d/l] |