Shenpen has asked for the wisdom of the Perl Monks concerning the following question:

Fratres reverendissimi,

after reading the documentation, my problem is that I think this module was created with the concept in mind that programmers create web pages (via hand-typed code). IMHO programmers should not create web pages, because 1) webdesigners have to make a living to :-) 2) it will be ugly 3) the programmer will constantly be harassed to make it prettier and programmers usually hate both to be harassed and to make cosmetical modifications to anything.

So my approach to web programming would be to:

1) have a webdesigner create a web page with a WYSIWYG editor

2) let's take this pretty web page and insert special tags in it for the dynamic, CGI-generated content

3) write a simple Perl CGI program that reads this HTML file line by line, if does not find special tags the simply writes it to STDOUT (to the web server), and if it finds, then does something special.

For example, if the program encounters a !!put:'any perl code or expression'!! tag, then it would eval() the expression or the code (if it's code, it should end with return, of course), and writes the result. More tags can be made for non-printing code, or to print something with an iteration (tables, reports, besides CGI, this stuff could be used to create HTML-based reports, even business documents like invoices), etc.

It's very easy, I'm almost done with it, except for the iteration stuff, that seems to be fairly hard (the basic logic is that a section of the HTML file should be repeated while the code in the special tag returns a defined value).

But isn't there a module for it? It's so simple that I'm sure someone invented it long ago.

Servus humilis,


Replies are listed 'Best First'.
Re: A different approach to CGI
by valdez (Monsignor) on Aug 08, 2004 at 21:18 UTC
Re: A different approach to CGI
by bradcathey (Prior) on Aug 09, 2004 at 00:55 UTC

    One word (already mentioned): HTML::Template. But first...

    As a graphic designer by trade, I appreciate your tipping-of-hat to us creative types. But as a Perl aficionado, I can speak from the server-side as well. After 3 years of working with both, I humbly recommend keeping the HTML and Perl in separate files and use the magic of HTML::Template (as mentioned above) to marry the two.

    This will allow the graphic folks to tweak the design via their HTML editors, and make it easier to build CSS2 validated/accessible sites. Then let the Perl process the forms, validate the input, handle the database, and populate the templates.

    HTML::Template is your ticket. It is widely supported by folks in the Monastery, and other places. Enjoy.

    "Don't ever take a fence down until you know the reason it was put up. " G. K. Chesterton
Re: A different approach to CGI
by ysth (Canon) on Aug 08, 2004 at 22:24 UTC
    Just a caution: it's good to make sure that the page created by the WYSIWYG editor is actually standards compliant. There's one validator at For some reason, it seems that certain editors made by certain software companies may "play favorites" and create html specific to one browser :)
Re: A different approach to CGI
by bgreenlee (Friar) on Aug 08, 2004 at 21:18 UTC
Re: A different approach to CGI
by jonadab (Parson) on Aug 09, 2004 at 00:05 UTC
    after reading the documentation, my problem is that I think this module was created with the concept in mind that programmers create web pages

    No, quite the reverse if anything: is written with the assumption that HTML is so complex, programmers would want to use some other interface to write it. This is such an astonishingly preposterous notion that I don't feel any need to bother explaining why it's wrong. Using CGI::Lite for form input is fine, but in terms of output, it's better by far to write your HTML in an editor that shows you the actual code — preferably one that lets you split the window and see the HTML in one pane and the CSS in another.

    have a webdesigner create a web page with a WYSIWYG editor

    They can create a concept mock-up that way, but someone who knows HTML will have to rewrite it from scratch. The code that comes out of most WYSIWYG editors is so bad, it's not worth revising for a static page, much less trying to use it as a framework or template for dynamic content. The programmer will want each piece of the generated content to be wellformed, so that the pieces can be combined dynamically without producing a complete mess. Worse, if you take code created in a WYSIWYG editor and do something really radical such as resize the browser window, it's often going to fail rather badly. You don't want this headache.

    let's take this pretty web page and insert special tags in it for the dynamic, CGI-generated content

    If your generated content is anything more complex than filling in a couple of blanks, this is going to get you a completely unwieldy wreck of a mess that will be nightmarishly difficult to maintain. If you really must go this route, you should probably think in terms of PHP, which is geared more that way, but I don't advise it for anything remotely complex. Get an artist to draw you what the layout will look like, yes. Have them print it out and give it to the web developer on paper, and let the web developer figure out how to make it look that way. This will take a little longer initially, but you'll get a website that's easier to modify later without screwing everything up, and you'll get a website that deals better with changes in the user's setup, such as resolution, default colors, and so on. (One of the many things WYSIWYG editors don't show you is when you commit the cardinal sin of specifying a foreground color without a background color or vice versa. This is generally obvious if you're looking at the code.)

    ;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print

      I think you are being a bit hard, and perhaps a bit opinionated here, but maybe those things are not serious problems. actually grew out of the need to handle a whole variety of CGI related tasks, not the least of which originally was from handling. But, like topsy, it grew and now it handles just about any aspect of CGI including generation of HTML, if you want. It is viable to only use parts of it, and many of us do that, or you could, as you suggest, use alternative modules.

      They can create a concept mock-up that way, but someone who knows HTML will have to rewrite it from scratch.
      Really? I use hundreds of forms each month that are done that way. We generally don't do any re-wruiting at all! We can't afford the time or the effort just to satisfy pedants. The HTML is done in Dreamweaver or something similar and when finished it validates with the stabdard validator. Why do I need to re-write it?

      But we also use 'form components'. Many of our applications use the same basic form sections over and over again. So why re-write them at all? We have currently about 80 form components on our server which are carefully crafted, have the CSS embedded in them and which are well documented so we can ensure that when they are combined into another page they will work seamlessly - and they do.

      Our general rule is to give the designer a paper and pencil mock up of what we need the forms to look like. The graphic designers use the CSS to create the overall look of the site and when it is all merged it works well. In fact we have one client who just today turned on a complete re-design of their intranet. Over 45,000 lines of Perl code required not a single change, nor did any of the 187 form based pages on the site. The whole thing was done in CSS and the form components are called out by the wrapper templates in the templating engine. Oh, did I mention that not a single HTML or CSS document was touched by hand? The HTML is edited in Dreamweaver and the styles are handled in StyleMaster.

      And why introduce PHP into the mix? We have inherited some sites that use PHP, and we are working as hard as we can to get rid of it! Until recently I did allow one programmer to use PHP for some sites where clients were already using it. But as of a week ago we instituted a no-PHP policy. We get far better operation and much greater uniformity of installations using Perl than we can with PHP. With any PHP stuff we have we usually end up with the sysadmins installing additional libraries or modifying things so it can be made to work. It is far saner for us to have all of our servers basically configured the same way using Perl so we don't have major re-work headaches when we do any upgrading.

      The HTML generated by the WYSIWYG applications may not be ideal, but it is servicable, the same goes for CSS code. So lets admit that these systems are in fact workable and they do work in some pretty big systems.


Re: A different approach to CGI
by trantor (Chaplain) on Aug 09, 2004 at 08:25 UTC

    Another module, especially useful to the ones used to the Microsoft ASP syntax, is Apache::ASP.

    Like I said the syntax is ASP-like but the code inside the <% %> delimiters is Perl.

Re: A different approach to CGI
by Shenpen (Beadle) on Aug 09, 2004 at 19:07 UTC
    Thank you all very much, especially Valdez for linking the article - you can imagine how loud I laughed when it started with "Go on, admit it: You've written a templating system. It's OK, nearly everyone has at some point." BWAHAHAHA :-DDDDDDDDD - this Perlin guy is a mindreader :-DDDD
      But he was right wasn't he!

      At least my only attempt to write a templating system was back in 1996, but I did it. I think it is actually some sort of rite of passage for CGI programmers.

      Biggest joke is, I got an upgrade recently for a CGI product one of my clients uses. For years now it has been based on HTML embedded in the Perl code and output using <<HERE print statements. They just added some very basic templating, but, oh, they use a home grown engine! What a nuisance, whch rock have these guys been hiding under?