CGI.pm HTML shortcuts

[brpsss]

I've noticed a lot of posts where people have recommended using the shortcut HTML functions inside the CGI module..

I haven't done this, because I like to keep control of the HTML that I write.. but are there other advantages to using the shortcut other than code becoming shorter and easier to read ? like speed ?

Also, has anyone here used CGI_lite ? I compile some of my code into executables, and I was wondering if CGI_lite could make a difference in the size ?

Thanks

[OeufMayo]

I like to keep control of the HTML that I write..

<AOL>Me too!</AOL>, but that being said, I never had been disappointed by the HTML output of CGI.pm. It's not as if you're using softwares like Dreamweaver, Frontpage or GoLive, which rely mostly on the inability of the user to actually write HTML, and thus output their own more or less mangled version of HTML.

CGI.pm on the other hand doesn't produce automatically HTML, you can mess up any way you want with the elements attributes (which is wrong), or put elements in the wrong places (TABLE tags in the HEAD, tags after the HTML ending, etc...). The big advantage of CGI.pm is to automatically generate valid XHTML, which is a Good Thing™.

For the speed question, everything comes at a price, and your process will use more resources to call the HTML tags from CGI than to simply print an interpolated string, but you usually doesn't have to worry about it as it is not a huge bottleneck (provided that you imported the html tags beforehand). If you already use CGI.pm in your script the overhead of generating the HTML is negligible, in my opinion.

If speed really matters, you should probably use mod_perl instead, with a Template-Toolkit handler. I have not tested this kind of configuration, but it should give quite good results

HTML Here-docs might be fine for small task, but if you have to generate tons of different pages with bazillions of different parameters for each, I'm not sure the guy who will eventually look up at your code later will appreciate that 4/5 of the program is embeded HTML with fragments of perl scattered all around...

<kbd>--
my $OeufMayo = new PerlMonger::Paris({http => 'paris.mongueurs.net'});</kbd>

[brpsss]

It might be an FAQ, in which case, I am sorry... but how do I import html tags beforehand ?
Thank you for taking the time out to explain.. you're right.. I have messed up my HTML a lot, when I do it myself.. and of course, an automatic generator won't do that. I don't really know too much about XHTML yet (its something to do with XML, right ?)
Thanks

[OeufMayo]

Everything about importing methods in CGI.pm is explained in The Fine Manual that you should Read. A copy is available here.

All the infos you want about XHTML and more (really more) can be found at the W3C site. Here's the abstract of the XHTML 1.0 recommandations:

This specification defines XHTML 1.0, a reformulation of HTML 4 as an XML 1.0 application, and three DTDs corresponding to the ones defined by HTML 4. The semantics of the elements and their attributes are defined in the W3C Recommendation for HTML 4. These semantics provide the foundation for future extensibility of XHTML. Compatibility with existing HTML user agents is possible by following a small set of guidelines.

<kbd>--
my $OeufMayo = new PerlMonger::Paris({http => 'paris.mongueurs.net'});</kbd>

[mpolo]

If the output is really 4/5 HTML with a smattering of perl, the eperl program works nicely. This automatically generates the Content-type headers. Anything that's inside a "special" HTML tag <? !> is taken to be perl, while everything outside is taken to be HTML. The shebang line changes to something like #!/usr/local/bin/eperl -mc. Eperl calls the perl compiler/interpreter on the machine to handle the perl parts. Supposedly you can get it to work with mod_perl as well, though I haven't tried that myself.

[tye]

Please enter "eperl" in the search bar at the top of this page for some dissenting opinions on eperl.

        - tye (but my friends call me "Tye")

[Ovid]

In addition to what others have mentioned, here are some other reasons to consider the shortcuts:

• CGI.pm now outputs valid XHTML. HTML is dying (thank goodness). XHTML is like use strict; for HTML.
• The shortcuts effectively allow a syntax check of your HTML. It won't catch the HTML equivalent of "logic errors" -- such as having 4 table columns instead of 3 -- but at least the HTML will be formatted correctly.
• You cannot forget to close a tag.
• You cannot misnest tags.
• Checkboxes and the like are a snap, once you get used to the new syntax:

  print $query->checkbox_group(-name   => 'group_name',
                               -values => ['eenie','meenie','minie','moe
  +'],
                               -default=> ['eenie','moe']);
  

Just be sure to use the shortcuts appropriately. If you're trying to create an application that others will be downloading from the net, or if you are only creating one or two dynamic pages, the shortcuts are simple and easy to use. However, if you are doing something much more extensive, consider using a templating system.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[redmist]

One reason I like to use CGI for my HTML is because (to me at least) it makes the code more readable. If I just print the HTML itself, it muddles with my eyes because of the changes in case and the prevalance of angle brackets.

redmist
Silicon Cowboy

[brpsss]

I try to use the really cool HERE document feature whenever I have a large HTML block to write... it make the code nicer looking...

and my HTML is lowercase.. but thanks for the input..

[mirod]

A good example of the kind of benefits using CGI.pm brings is that it recently started outputting XHTML. So you get buzzword compliance essentialy for the price of upgrading the module ;--). And at the same time you are now able to use all the XML tools on the generated XHTML. It would be much, _much_, harder to go through all of your scripts to change the case of tags and add the extra ' /' at the end of empty tags.

[petdance]

Well, of course there's no way that generating code programatically is going to be any faster than static strings. However, I have to say it over and over: Speed is not everything. Before you worry about speed, figure out how slow your solution is. Chances are it's unnoticeable.

print   start_html( PAGE_TITLE ),
        h1( PAGE_TITLE ),
        start_form( -method=>"GET", -action=>$q->self_url ),
        input( {type=>"text",name=>"text",size=>40, value=>$text} ),
        input( {type=>"text",name=>"width",size=>5, value=>$width} ), 
+" pixels wide",
        submit( -value=>"Muck!" ),
        end_form(),
        table( {border=>1,cellspacing=>0,cellpadding=>0},
                Tr( th( "Original" ), th( "Mucked" ) ),
                Tr(     td( img( {src=>$filename} ) ),
                        td( img( {src=>"mucked-$filename"} ) ),
                        ), # tr
                ), # table
        end_html();

You can see the entire structure of the page right there. I can't goof up closing TABLE tags (a particular bane of Netscape), everything has to be well-formed, etc etc etc. Is that worth a few milliseconds of execution time? In my book, yes.

xoxo,
Andy

# Andy Lester  http://www.petdance.com  AIM:petdance
%_=split';','.; Perl ;@;st a;m;ker;p;not;o;hac;t;her;y;ju';
print map $_{$_}, split //,
'[e-mail]'

[damian1301]

I use it for these reasons


• It works EVERY TIME (unless you don't have the module, etc...) with no escaping of characters because that is all done, within the script.
• It saves a lot of space that I don't have to type like the brackets and all the trash.
• The sticky fields come in handy, often.
• If the HTML tag doesn't already exist in the module, then you can just simply declare it on the command line and voila!
• Makes it MUCH more readable regaurdless if it is uppercase or lowercase, brackets or slashes.


Just my .02 cents...

Tiptoeing up to a Perl hacker.
Dave AKA damian

[Rhandom]

What are your goals? If you are writing stuff on your own, for your own use, that won't change very often, then sure... use CGI. If you want it to be more maintainable, to separate content from function, then you should really should move the content out of the cgi. That is move the html into separate files.

There are many ways to do this, but this allows you to modify the html without introducing errors into your cgi. Beyond this, imagine you hire somebody to do the graphic design for you, you can hand them ugly HTML, and they can make it look as pretty as you like.

To go a step further, you might consider a templating system that allows for overriding content. This would allow you to use your same cgi's in another language or would allow you to let users choose colors or format.

So, what would you like. In the long run, I think you would be happier with separate content files that can have their own revision history.

[brpsss]

Yes, EXACTLY!! Hiring a web designer is what I wanted to do.. but I was sure they wouldn't like the nasty $ signs in the HTML code..

Thanks for the suggestion about templates.. for the moment, this is more or less for myself, I am the only person writing this.. but the team is expected to grow larger soon, and separating the HTML information is something that I would like to do when I finish work completely on the CGI portion...

[Rhandom]

We've done it here for a long time. We have 500,000 to 1 million cgi hits a day. All of them pull the content in from external files that is overridable depending upon which host you are on.

As for the $ signs. Our html guys haven't cared about it. However, I would suggest using something with a beginning and end delimeter such as __variable__, or ^variable^, rather than $variable. Using beginning and end delimeters avoids the problem of swapping $20.00 or putting a variable inside of \w text (try to swap out ABCDEFG$variableHIJK).

Even if it is a small operation, having the code external will save you time in the long run.

[virtualsue]

Heh, how many more advantages do you need other than "shorter and easier to read"? ;-)

Here's another advantage for you. I think the built-in "stickiness" (which can be overridden) you get with the form element shortcuts is quite useful.

[zakzebrowski]

Hi. Personally I use the tags within the perl code I write. This is because of the fact that most of the time I'm writing perl I'm using it for my personal use, but I also write Cold Fusion / ASP code. Cold fusion code is basically html tags with cold fusion extension tags that are based on html tags. ASP, on the other hand, is still HTML but with a different application infrastructure (if you can call it that) underneth, a mix of html and custom tags and optional vb-type code. Therefore, I am comfortable writing the tags within my perl code because it allows me to change languages quickly. Of course, I only use perl when I actually have a chance to write web code for myself. (Though I will be looking at php at some point because it does have some perl-ish features and it's similar to cf/asp, though, imho, it doesn't have the openess that perl supports.)
Zak

[murphya]

Why not use CGI.pm? It is easy, clean and quick. Additionally, even with standards changing pretty quickly, you don't have to worry about altering all of the code by hand - just update the module. It also forces you (with no work on your part) to use the latest methods.

The best place to learn about it is via the perl.com website - see the "How do I write CGI?" link.