No offense, but i stopped using HERE DOCS moons ago, you should too.

Hi jeffa,

What have you got against here docs? Or is this just something against here docs to generate (X)HTML?

HERE DOCS were very wonderful before i started using HTML::Template, Text::Template, and the uber Template. Since then, i discovered that HERE DOCS tended to clutter my code, besides ... being able to seperate out other languages from your Perl scripts is good. eduardo recently introduced me to Class::Phrasebook::SQL which allows you to abstract SQL code. It may seem like more work at first, but you get better and faster, and soon you find that HERE DOCS are an unattractive, cludgy solution. This doesn't mean that i won't ever use them again, it just means that i found something better for me.

(P.S. you can witness some of my older CGI HERE DOC ways over at my Lingua::Ispell review)

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)

Beware! Templates are great for "slightly dynamical content" - and as such used by me. They are not apropriate for heavy-duty dynamical content.

Where did you get that information from? Whether the content is "slightly" dynamic or "heavily" dynamic shouldn't matter. Time is spent to load the template and process it, more processing means more CPU time, but this by no means constitutes "not an appropriate solution."

And the conclusion that is hinted at ... that HERE DOCS are better for "heavily" dynamic content than templating solutions seems very absurd to me - especially when you realize that templating solutions allow you to abstract away components that can be included and cached ... have fun trying to accomplish that with HERE DOCS.

I really get the impression that most advocates of HERE DOCS have not fully grasped just how much there is to be gained by switching to a templating system. They are both great tools, but the latter is a much better fit for delivering Web Applications.

UPDATE: (a reply)
HD with interpolation is indeed already a simple templating system, but it's one that will allow you to paint yourself into a corner. Do yourself a big favor and start using Template modules more than you already might be, then you might realize that HERE DOCS are only good for quick and dirty solutions. (I really believe that you have only a cursory experience with Templating modules - i did a search on your past nodes and none of them mention a single word about Templating except the ones in this thread.) Besides, aren't you just needlessly reinventing the wheel? ;)

Oh, and believe me ... i do this for a living.

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)

My advice is that you never, never, never want to try to convince someone online by the claim to authority, I do this for a living.

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.

We probably should discuss this out. It is important.

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]

Don't try to warp the Perl/Template ordering. Just believe me. Been there - done that.

Bye
 PetaMem     All Perl:   MT, NLP, NLU

The "time spent" on generation argument doesn't matter if the generation of the content takes an (or some) order of magnitude more than the generation of the markup and if the resulting content is not cacheable.

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. :-)

Bye
 PetaMem     All Perl:   MT, NLP, NLU

And I am very unhappy about the quality of the perl code of the OSS project we used as basis for our NLP portal.