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

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.

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();
[download]


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

I wasn't ragging on CGI's html methods because they don't work in some way. I was down on them because separating content and presentation happens to be a very good bargain. Writing CGI's html methods to produce desired output is a bad code factoring.

And it sounds like your company realized the same thing. Yes, you use CGI's html methods. But you don't code them up. Instead you autogenerate it from regular HTML. (And presumably you could take the original, put it through standard design tools, and then re-autogenerate the CGI code. If you can't then take the energy to figure out how to make that doable. You will make up for the effort in savings on maintainance.)

That works. That addresses the objection squarely.

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.