Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

Should One Use to Generate HTML?

by sierrathedog04 (Hermit)
on Jan 01, 2001 at 05:18 UTC ( #49149=perlquestion: print w/replies, xml ) Need Help??
sierrathedog04 has asked for the wisdom of the Perl Monks concerning the following question:

Several days ago some wandering perl monks advised me to learn to use It seems like a great help in accessing cgi form variables: instead of parsing my environmental variables to get rid of those "%" symbols inserted by CGI, I simply call param() to get my form variables back the way they were entered.

I wonder, however, if it is worthwhile to use to write HTML. For instance, I was surprised to note that the startform method does not include a built-in parameter to give the form a name. (A workaround is to make the first argument to startform be an associate array whose key value is "name").

Because of gotchas like the above the module, when used to write HTML as opposed to parsing form values, might arguably be harder to read than simply printing the desired HTML as a string direct to the browser.

In fact, I came across an old tutorial at the University of South Wales in Australia which stated " is a perl module providing functions/methods that make it easy
  • to access data items and other infor available to the CGI script
  • to produce HTML output from the script (IMO this is debatable)

Before I start using to write all of my new dynamically generated web pages, I was wondering what is the most common practice of the monks. Do they print their HTML directly to the browser as strings, or do they use's functions for this purpose?
  • Comment on Should One Use to Generate HTML?

Replies are listed 'Best First'.
Re: Should One Use to Generate HTML?
by Trimbach (Curate) on Jan 01, 2001 at 08:06 UTC
    When I first started using I had the same thought as you... templating issues aside (you should use a template system of some sort for large blocks of HTML) what's the big difference between print h1("Hello World"); and print "<h1>Hello World</h1>";. I mean, really.

    But as time passed the light went on and I realized that really does make life easier in HTML generation... not for big blocks of static HTML but for all those dynamic things that you're probably using a CGI for in the first place.

    For example, think about writing the HTML for a form with checkboxes where some of the checkboxes are pre-checked. Which checkboxes are checked depends on logic within your CGI. If you try to do this using print statements and generated HTML you're going to spend an enormous amount of time dealing with if/then statements to determine if "CHECKED" should appear in your static HTML or not. Using it's as simple as passing references to a couple of arrays and you're done. Piece of cake. also makes auto-generation of table tags a total breeze.

    In short my vote is:

    • For parameter values, use always always always.
    • For small amounts of static HTML, generate the HTML tags however you want... I sometimes use both regular tags and tags interchangeably if I'm feeling lazy.
    • For non-static HTML more complicated than simple variable interpolation, save yourself the hassle and use
    • For complicated formatting (like using tables for layout) or for large sites (i.e., your CGI is going to produce more than one completely different type of web page) you ought to use a template, either using a home-rolled regex solution (a la the solution in the Ram) or if your needs are more strenuous, one of the many modules.

    Gary Blackburn
    Trained Killer

      I use for accessing params and for generating forms. This isn't just to make the logic simpler when generating checkboxes, but mostly because it remembers settings for you.

      This is useful when a user submits a form, but with some fields not filled in. The code generates a warning message which is displayed and then I just call the function to generate the form again and hey presto, everything the user entered is there. Very useful.

      I don't use for generating the rest of my HTML code though, I prefer to that by hand.

Re: Should One Use to Generate HTML?
by repson (Chaplain) on Jan 01, 2001 at 05:37 UTC
    It depends on the project..

    Use html generation for small projects where you would otherwise inline html and only coders familiar with CGI's functions will want to edit.

    Otherwise it may be better to learn HTML::Template or the template toolkit to allow you to write and maintain you html code seperatly.

    But do continue to use to parse your form variables, it's the best solution for that.

Re: Should One Use to Generate HTML?
by tame1 (Pilgrim) on Jan 01, 2001 at 07:59 UTC
    Although such constructs are not IMMEDIATLY apparent, if you
    read the pod docs, you will see that html which is not
    "built in" can be added to any function.

    However, I agree (at least in part) with the others when I say
    that using to write your html is extremely usefull if your site depends on a back end to produce the text, such as pages which are dynamically generated from data in a database, etc. For static flat files, it is literally a waste of time - yours, and your servers. can be and often is an unbelievable help in coding many sites and interfaces. It can also be an albatross if used when it's features are more work than regular html.

    What does this little button do . .<Click>; "USER HAS SIGNED OFF FOR THE DAY"
Re: Should One Use to Generate HTML?
by ichimunki (Priest) on Jan 01, 2001 at 05:25 UTC
    I haven't used CGI. Ever. And I'll tell you why. Bad Teachers.

    If you look forward to having to debug the heck out of your HTML which is hardcoded into Perl or if you like having to re-debug all your HTML once you change the logic of your script, by all means, go for it!

    On the other hand, if you want the module to keep track of closing tags and handling the headers and stuff like that, I'd suggest learning it now--before you are used to either way of working. In the long run, I'm guessing you'll be a lot happier.

    (That's a "yes, use the module" if you can't tell.)
Re: Should One Use to Generate HTML?
by davorg (Chancellor) on Jan 01, 2001 at 18:33 UTC

    In my opinion, using's HTML functions is something that can be useful on smaller scale scripts, but for anything large, I'd use a templating system. My favourite is the the Template Toolkit, but "other templating systems are available".


    "Perl makes the fun jobs fun
    and the boring jobs bearable" - me

Re: Should One Use to Generate HTML?
by Fastolfe (Vicar) on Jan 01, 2001 at 22:24 UTC
    For instance, I was surprised to note that the startform method does not include a built-in parameter to give the form a name.

    This works for me: start_form(-name=>"form_name")

    A lot of things aren't documented in the docs because they're redundant. You can generally assume that any parameter like that can be passed just as I did it above and it will work. Generally, this is the way to pass any complex arguments to any CGI function. The "standard" arguments (that require no named parameters) tend to be very basic. Otherwise, you'd have functions that take a ton of standard arguments, which makes it difficult if the only one you care about is the 6th. The idea is to make your code more readable, not less. A million unnamed arguments for each function is impossible to maintain.

    I think other posters have already neatly summed up the various reasons people use or don't use In the end it's personal preference. I've heard people in the past say that using to build your HTML pages means you don't have to be an expert on HTML, but I've found that in practice, you have to really know HTML before these functions will make sense when building the pages themselves.

Re: Should One Use to Generate HTML?
by epoptai (Curate) on Jan 01, 2001 at 19:42 UTC
    One strategy is to only use and import the CGI functions you feel comfortable with. For instance, header() and end_html() are consistent and useful to name only two.

    Also it's pretty great for rapid prototyping when you can crank out one line html documents like this:

    print header,start_html,start_form,textarea('me',"$x",20,70),submit('m +e','go'),end_form,end_html;
Re: Should One Use to Generate HTML?
by Chady (Priest) on Jan 01, 2001 at 22:51 UTC
    whenever I want to generate an HTML page, I use templating.
    I was working on a submission form for the company I work at, they want the user to fill in some fields, then click proceed, a new page is generated to fill his company information, all what he entered previously should submit too.
    so I made an external template .html file, the script reads the file, and checks the lines for comments, like <!--somevalue--> and substitutes them with some value entered previously..
    this way I can save myself the trouble to debug all the javascript, or coding that is supposed to be generated with the page.
    how may times have your script generated an error for that un-escaped @ in the e-mail address written in the generated page?

    I say definitly go with CGI, but when it comes to big chunks of static html... template.

    Chady |
Re: Should One Use to Generate HTML?
by brother ab (Scribe) on Jan 04, 2001 at 17:03 UTC is very good module. But - TIMTOWTDI. Before you start to use it I want to say some words pro et contra. Order of my notes is irrelevant and does not correspond to importance.

    This module is large. And, therefore, slow. Especially in pure cgi envirionment (mod_perl enables to preload modules). CGI3 is managed to solve this problem - it is split in several parts and you can load only what you need.

    Where are you going to use it? In apache+mod_perl environment you could try other modules - Apache::Request (or Apache::RequestNotes) and Apache::Cookie for request params and cookie parsing. They use apache API to make work and hence notable faster.

    What is scale of your project? Several dynamic pages or many-many pages with similar structure and/or reusable parts? In last case you could consider one of special kits (i prefer two - HTML::Mason and AxKit but it is to your taste). All (or almost all) these kits provides even more comfortable access to request parameters and different wonderfull means to produce HTML. Many of them work in pure cgi environment.

    Hope my thinks are helpfull and not very intricated :)

    -- brother ab

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://49149]
Approved by root
[stevieb]: did my pull request challenge today, Locale::gettext. Weird layout for a dist, and I have no idea how to use it, but it's always nice when you can force someone else's work be use strict; and use warnings; compliant :)
[stevieb]: ahem... s/no idea how to use it/didn't read enough as to what it's used for/
[stevieb]: interestingly enough, someone else got my Devel::Examine:: Subs distribution for their PRC, and I applaud the change. This dist is extremely complicated and mostly obfu, but the person doing it understood PPI enough to change...
[stevieb]: ...something I had overlooked in the extreme depths of the core functionality. After merging, then a couple of extra tweaks, I still have 100% test coverage. Yay for people who write tests!

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (7)
As of 2017-01-24 01:16 GMT
Find Nodes?
    Voting Booth?
    Do you watch meteor showers?

    Results (199 votes). Check out past polls.