I prefer HTML templates over raw Perl, because I live in the hope that the code at one time will be "rock solid ^™" and won't be changed anymore, while I might want to change the look of the site more often, which is easily attained by using (one or more) templates.

Of course, once the code is done, I seldom go back and change the look and layout, but I've turned more and more to XML and XSL(T?) as a templating mechanism, a bit crude and resource intensive, but it delivers nice results fast (mostly on an intranet server for 6-10 people not generating many hits, and regenerating the documentation is done by saxon offline anyway).

Offtopic question of the minute : Does anyone know how to read data from arbitrary files using XML/ECMAScript ? Like, read the width and height from a .jpg file ?

My first objective for using templates is to completely eliminate duplication of both code and markup.   This will be done partly by having param() calls to external files of arrays o' links and to external files of text content.   One markup template, one script, and a passel o' content and link files.

My second reason for using HTML::Template is that it's a good excuse to continue learning Perl by doing Perl.   8^)
    cheers,
    Don
    striving for Perl Adept
    (it's pronounced "why-bick")

For some places, it's a large fence: the artists, designers, attorneys, etc. don't touch the perl code, and the developers do not affect the "look and feel" (e.g. the HTML). Of course, there are times when you need to communicate with the other group, especially for large changes, but in general in keeps everyone happy. It's kind of like having a subroutine in embedded in the HTML - the designers put a call to the subroutine in (say, to get a list of phone numbers) and the programmer promises to produce that list of phone numbers wherever that template is called.

Template systems at their best function as a contract - if they (the HTML designers) give this template, the developer will promise that it will get replaced by exactly *this* and *that*: no more, no less. It really frees the developer from a lot of finger pointing and blame. As long as their code honors their end of the contract, they cannot be blamed for anything regarding the look (and, if a good contract, even the functionality) of a site. So they can work on coding, instead of being blamed for a display problem that is finally linked to the lack of a closing TABLE tag by some designer. :)

Says jettero:

so my lunatic boss can edit the html without destroying our dynamic content.

That's why I use them. When I was at Time-Warner back in 1994, I got tired of having the designers come to me to ask me to change the CGI programs so to make the text blue instead of green. And of course I didn't trust them to edit the program directly. I invented Text::Template so that I could tell them to edit the template files and leave me alone.

It worked, too.

<aol>Me Too</aol>

At BlackStar.co.uk we need fairly fascist^H^H^H^H^H^H^Hstrict QA/revision control systems. By templating all the markup away from the code it makes this process several orders of magntitude easier.

Designers can modify what any page, or component used across several/many pages, looks like without having to go through the code review / release cycle, and coders can create code that isn't full of HTML, thus making the code much easier to read and maintain.

Tony

Embedding any scripting language inside of HTML is a lot prettier than calling 600 echo/print/document.writeln()/etc... commands to print your page out. It's not just a comfort issue, it really is easier to read. Also, it allows you to use a nice IDE like Homesite to colorize all of your code AND your html AND your embedded SCRIPT tags (I refer to Javascript for the browser).

My latest project has been writing a couple of scripts that convert my poetry from a text file (I'm going to fiddle with XML here soon) into HTML that is consistent with the theme of my site.

In the past, I've gone through and done it by hand. I've only got about 10 poems. But my wife has nearly 60 poems. This way once I write the script, all the work is in making the templates (which is easy!).

That's my $0.02

It's interesting to me that all of the responses to this post have discussed using templates for creating web pages. Whilst I do like to use TT2 to create web pages, one of the things that draws me towards that system rather than something like HTML::Mason or HTML::Template is that it is purely a templating system and doesn't assume that it's being used to produce HTML. You can use it just as well to produce just about any other type of ourput.

For example, I'm just working on an article which demonstrates how I've used TT2 to produce XML files which make up a data feed that we pass on to our customers. I'm also working on a design so that my company can produce all of its invoicing and form letters with templates. The templates will be LaTeX files which will contain TT2 directives which expand to display the relevant data. In both of these examples, the main advantage is, once more, the fact that the designers of the XML files or the invoice templates don't need to know any Perl at all.

So I use templates not just because it makes it easier to impose a consistant look and feel on a web site, but because it makes almost all of my Perl work easier.

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

HTML generation is the most widespread area where template technichs are used. For the historical reasons. And almost all template kits was started with this goal in mind. Some of them (not only TT2) overgrow these boundaries and became universal template kits.

I have started to use HTML::Mason about 1.5 years ago to generate HTML pages for Intranet site. Now I use it to generate XML (which then transform to HTML with AxKit). Moreover - I use it to generate C++ code! (and not only C++...)

-- brother ab

For a good read on the aspect of separation of content, code, and markup, check out this article.

Having been in the situation of trying to champion/explain/maintain templated sites in a large corporation, and having been caught up in the "code must always be separated from markup" daze, this article helped me see that deciding not to always strive for maximum separation is not a bad thing.

Yuck. It reads like a combination marketingdroid-artiste.

Am I alone in wishing that we could have a media-free¹ environment in which people could express their ideas without their message being tweaked by layout or fonts or backgrounds or "vision" - am I the only dyed-in-the-wool intellectual left? I want to hear ideas, not hype.

¹ media, plural of medium, meaning the materials used to make a presentation, like canvas, oil, <blink> tags, clay, VRML objects, ink, Ariel fonts, and so on. I'd settle for a "one-medium" environment².

² Like lynx intended... Gahhhh. This belongs on purists.org or something.

While I enjoy your vile distaste for the specious nature of information delivery, I am more amused by sophistic approach you use to proclaim your view as intellectual.

Should we have quit building homes out of mud?

I completely agree that the purity of minimalism is virtuous, but it assumes that 'ideas' can only be expressed through a medium of words-concepts. It denies genius and creative expression given via color, shape, and demension. Not that I've seen any media that expresses genius such as this yet, but we are still in a genesis of the technology.

While I can quite sympathize with what you must view as a total bastardization of purity, I'm actually more excited by the new concepts and idea's that arise from those that have yet to find the tools they require to adequately express their ideas-intellect to the world.

coreolyn