Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Should One Use CGI.pm 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 cgi.pm. 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 CGI.pm 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 CGI.pm 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 "CGI.mp 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 CGI.pm 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 CGI.pm's functions for this purpose?

Comment on Should One Use CGI.pm to Generate HTML?
Re: Should One Use CGI.pm 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 CGI.pm to Generate HTML?
by repson (Chaplain) on Jan 01, 2001 at 05:37 UTC
    It depends on the project..

    Use CGI.pm 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 CGI.pm to parse your form variables, it's the best solution for that.

Re: Should One Use CGI.pm 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 CGI.pm 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.

    CGI.pm 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 CGI.pm to Generate HTML?
by Trimbach (Curate) on Jan 01, 2001 at 08:06 UTC
    When I first started using CGI.pm 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 CGI.pm 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 non-CGI.pm 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 CGI.pm it's as simple as passing references to a couple of arrays and you're done. Piece of cake. CGI.pm also makes auto-generation of table tags a total breeze.

    In short my vote is:

    • For parameter values, use CGI.pm always always always.
    • For small amounts of static HTML, generate the HTML tags however you want... I sometimes use both regular tags and CGI.pm tags interchangeably if I'm feeling lazy.
    • For non-static HTML more complicated than simple variable interpolation, save yourself the hassle and use CGI.pm.
    • 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 CGI.pm 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 CGI.pm for generating the rest of my HTML code though, I prefer to that by hand.

Re: Should One Use CGI.pm to Generate HTML?
by davorg (Chancellor) on Jan 01, 2001 at 18:33 UTC

    In my opinion, using CGI.pm'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".

    --
    <http://www.dave.org.uk>

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

Re: Should One Use CGI.pm 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 CGI.pm 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 CGI.pm 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 CGI.pm 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 CGI.pm. In the end it's personal preference. I've heard people in the past say that using CGI.pm 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 CGI.pm functions will make sense when building the pages themselves.

Re: Should One Use CGI.pm 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 | http://chady.net
Re: Should One Use CGI.pm to Generate HTML?
by brother ab (Scribe) on Jan 04, 2001 at 17:03 UTC

    CGI.pm 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?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://49149]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (13)
As of 2014-07-10 18:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    When choosing user names for websites, I prefer to use:








    Results (215 votes), past polls