A very large fraction of us do this for a living. Most people who do this for a living suck at it. The competent ones are painfully aware of that. Furthermore when they see an unknown person online falling back to argument from such spurious authority, it raises immediate red flags. If you are truly an expert, why can't you come up with something concrete rather than a vague catchall like that?

Therefore no matter what the temptation, don't start raising claims of being a professional. It only hurts your case.

Update: Tyop correction.

While I agree, that a templating system has many advantages over a simple here doc (HD), it is also true that a HD with interpolation is already a simple templating system.

Furthermore if you have a close look at all the templating modules at CPAN, you will find there some enabling "real perl processing", thus inlining perl into templates. Wuuuh... Bad idea. So instead of inlining text into Perl (HD), you inline a template into perl only to find, that you need more expressive power so you inline Perl into the text you inlined into Perl. Very bad.

Lets assume our standard case. For every nontrivial HTML document (heavy-duty dynamics), you have not only to interpolate variables, but also do some more processing which is done in some subroutines/submodules. So what do you do? You use Perl to generate the document and use HDs for the simple things/static parts.

Now to sum up what impression I really get: many templating system advocates are blind because of the greater expressional power of the templating system (compared to HD), so they try to apply templating to every document generation.

This is wrong IMHO. Speaking of expressional power you have

E(Perl) >> E(Template) >> E(HD)
[download]

Thats wonderful. And what happens when somebody wants to change the font color to red? You get your text editor, open the perl script, find your heredoc (wherever it is) and then change the font color. Oh wait, he prefers the font color to be blue instead. No.. green. And so on and so forth. Or other minor graphical changes that should really be the providence of the web *designer* as opposed to the web *programmer*. Templates of course avoid both of these issues. As for inlining perl in to text, <tmpl_var foo> is hardly what *I* would call perl code. And what about caching? You can't cache individual here docs.. you can templates. Not to mention templates can also help impose a more logical structure upon your program.

If you have choosen to provide far reaching look&feel configuration in your more-than-average dynamic pages (which you most probably have), you solve these kind of things with CSS.

BUT if you really need to have the font color changed quick & dirty, you will provide a button/selection box somewhere filling a var $font_color and in your (interpolating) here doc there will be:

<font color="$font_color">
[download]

Bye
 PetaMem     All Perl:   MT, NLP, NLU

A templating system (although called Perl Preprocessor) we have, are and will be using is Text:Vpp for dynamic document generation (mainly LaTeX files).

I have some advice:

From my experience as project manager: Don't get passionate about this (advocacy). You have found a nifty tool. But don't try to apply it to solve all (templating) problems you have. For some of them it is too big, for some it is too small. I didn't say it is useless. There's a big bunch of things where it is exactly the right thing.

From my experience as computer scientist: The expressive power of a given system is of course dependant on its - well - expressiveness. I mentioned the comparison between Perl, a *real* Templating system and HD. Of course everything is possible by extension. You may include even perl-code to a template to achieve some things, but then...

...From my experience as programmer: you really have messed up your design. What you planed to achieve - separation of code and data - for better maintainability,reusability etc. gets lost.

And finally from my experience as managing director of two companies whose core products are based on Perl:

I do this for a living too. :-)

Yep. We are now comparing apples and organges.

Please allow me to start over. Here is what i am passionate about: seeing someone use HERE DOCS to create their own half-baked "templating system" for the generation of HTML documents (i never said anything about LaTeX). Why am i passionate about that? Because i have extensively used HTML::Template and Template with great success, being able to finish on time, and being left with a very, very extensible and easily modifiable system. I am also passionate about it because i have used and seen other technologies that allow you to paint yourself into the corner a few months down the road. The reason i spoke up against your original HERE DOC code is that you cannot convince me that storing HTML inside some Perl code is better than storing HTML inside it's own .html text file. Sure i have to load it into memory ... but this is WEB PROGRAMMING!!! That time is so negligable, but then again, i am not producing LaTeX (and i will probably never have to).

Now then, i am not arguing that HERE DOCS are bad and should be deprecated, i just don't need them. If HTML::Template and/or Template (or HTML::Mason, Apache::ASP, CGI.pm) used HERE DOCS under the hood ... i would still use them! Again, my argument really is not about the technology that was chosen, but the failure to use an existing solution from CPAN.

So, if i have a need to create LaTeX, then i will most definitely look at Text::Vpp ... and i wholeheartedly thank you for introducing me to it. But ... i do HTML and plain old text.

Now then, a small rebutal:
"...From my experience as programmer: you really have messed up your design. What you planed to achieve - separation of code and data - for better maintainability,reusability etc. gets lost."

Well, exactly what have you done with HTML::Template? Until you "figure it out", you will most certainly lose your goal of content/data separation. The tool itself only lends you a hand to successful, maintainable, and reusable seperation. It's up to YOU to see that those goals are achieved. Speaking from my own experience, i failed many times, still stuck in my ways of thinking that certain bits of HTML still needed to be generated from the code. Once i learned what content/data seperation really means, my templates and code started to reflect it.

Now then, when i said i do this for a living, i was talking about Web Application Development ... HTML. For the record, anyone who does that for a living is a fool if they think that HTML::Template and Template are just "nifty tools" - they are quickly becoming necessary tools. Even PHP (which i still use where appriopriate), a templating tool in itself, offers at least two templating tools: Smarty and a PHP HTML::Template.

I am sorry, but your words are still those of someone who has not used these tools enough to give valid critisms ... yet! I want more proof, and not just your opinion. (And i should note that i am very skeptical about people who still use UPPER CASE letters in their HTML tags - that's a big "still stuck in the stone age" flag.)

And finally, for the record - i do not dislike HERE DOCS. I just shouldn't have to use them directly or have to scan through them to find what i have to change. God forbid that a web developer had to do the same ... and no, CSS won't always prevent that from happening! I consider HERE DOCS to be a quick and dirty tool for those quick and dirty moments when i need some quick and dirty results. But, tell me ... what advantage does using a HERE DOC have over

my $header = qq|<html>
<head>
<title>$title</title>
</head>
|;
[download]

and how do you achieve conditional branches and loops with HERE DOCS? (And yes ... i know that Text::Vpp provides this.) You build them yourself. That is what i was arguing against, and the fact that you just admitted you use an existing CPAN module to "manage" your HERE DOCS only strengthens the spirit of my argument: USE THE CPAN! ;)

But, for text (that includes HTML) ... i will continue to use HTML::Template or Template, simply because each HTML document gets to live where it should: inside an HTML document.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

The reason i spoke up against your original HERE DOC code is that you cannot convince me that storing HTML inside some Perl code is better than storing HTML inside it's own .html text file.

But, tell me ... how do you achieve conditional branches and loops with HERE DOCS

So now it's you trying to convince me, that it actually is better to store HTML *plus* code (conditional branches and loops) in "its own" .html text file.

Brother jeffa: Either you must be blind or just kidding (a lot). If I'd want that, I'd be using Zope (which we actually do for our WWW).

Bye
 PetaMem     All Perl:   MT, NLP, NLU

Since we are all discussing doing this for a living, the job experience that you described strongly suggests that you are in fact a PHB, immediately rendering suspect any technical judgements that you make. :-P

That said, I agree with your list of what matters and where the dangers are, but disagree with your ideas on how to get there. My general perspective on what should feed templating decisions can be found at Re (tilly) 6: Code Critique. The biggest single factor in most cases is that your decisions here determine who must necessarily be involved in different kinds of maintainance going forward. To me this fact is massively more important than factors such as how dynamic the content of the site is.

Both of these are a bit dated, but I still like the overview offered by this white paper on Template::Toolkit and Choosing a Templating System. The second one has an update coming, so you should talk to perrin about any templating-like system (eg Text::Vpp) that you like, telling him how it works, and why you like it.

The overhead offered by a good templating system is miniscule. For instance it is not a good bet that heredocs are going to be faster at runtime. But it is a good bet that the decision to use heredocs guarantees that pretty much anything involving touching HTML will need to involve a programmer, and anything involving changing the overall layout of the page will likely involve tearing your hair out. (CSS can only do so much of that for you on a complex site. Try rearranging what pages have what content and...)

It is also far from guaranteed that the decision to use a templating system will result in your winding up with well-defined data components that HTML people can manipulate without having to learn how to program. But you have a chance to get there if that is your up front goal and it really makes sense with how your company is organized.

So my personal opinion is that while heredocs are sometimes justified (I have certainly sometimes used them, particularly in cases when I will be the only maintainer and what the script does is simple), choosing to go that way limits the tradeoffs that you can decide to make. And normally there is a better tradeoff available which can be reached with a templating system.

Of course the flip side is that reaching the right tradeoff will also mean having the programmers only using the extra expressiveness that the templating system offers to express the solution that you want..and no more. Unwarranted further use of available expressiveness is an option that I agree can quickly lead to a big ball of mud. But there is no reason why it can't remain just that, an unused option.

Mine view is that it is not about separation of code and data - but rather about separation of business logic and presentation. This is a valid line of separation. Presentation beside pure visual treats does include some logic and thats why logic is supported by the templating solutions.

Actually I agree with *this*. If there is a justification to export code (not just static content plus some "interpolation") to a templating system, it might be exact for this reason.

But I have a hard time to see where it would improve maintainability, because then in order to change the presentation layer (template) you have to send your programmers too. (One of the arguments was, that templates don't need programmers. More precisely - the work on (changing) templates.)

And as for the programmers: I have an *extremely* hard time to see where this code splattering would improve readability.

Bye
 PetaMem     All Perl:   MT, NLP, NLU