That was the problem - which one?

It doesn't really matter, as long as it:

• Meets your immediate needs and appears to have a reasonable chance of meeting your future needs.
• Seems reasonably stable.
• Meets your maintenance budget (that is, it's less work to maintain than if you had to do it yourself).
• Has sufficient documentation.
• Runs on your target and development platforms.
• Reasonably compatible with existing deployed systems.

A day's worth of research on templating systems would have revealed a lot. Now maybe writing this for your own organization was the right approach -- I don't and can't know that. Yet I do want to bring up the risks involved, as I would if someone in my organization were to do the same thing.

The points you mention make sense, and ignorance sometimes is bliss. It allowed me to ask for comments on an implementation idea which may make most experienced programmers yawn. E.g those which never felt the need for a templating system doing web programming.

A day's worth on research reveals much, and it affirmed my suspicion that chosing one of them templating systems is a wicked problem. Every choice has its consecuences you cannot foresee. Lack of experience and knowledge ever lead me to take steps as small as possible, and the more cautious I am with wicked problems; so, if I don't find the right tool for this approach (due to lack of time, experience - not knowing how to help myself -, laziness, tiredness, whatever) I roll my own which more often than not I can throw away fast (or which offhand is so crufty that it must be refactored anyways :-).

It is not easy. Which is the right way to go? A clean approach to W3C compliant pages is that of HTML_Tree (or HTML::Seamstress). Petal looks very powerful, but its syntax is not very intuitive. HTML::Template is scared about callbacks; Catalyst messes with attributes because it's cool (I apologize in advance for that statement) etc. All of them in themselves mix design with function: <TMPL_VAR foo> is a design choice, as is the language of Petal. What is "standard" here? Each has it's own idea of why you must subclass what when, and the interfaces are deliberate.

What suits the needs of a project which you don't know better (four sheets of draft don't say much) - DOM parsing, pipeline or callback model? a mix? what about caching? What impact on load has your decision? Are changes forseeable, and to what extent will they go? Who are the people you are developing for? what are their skills? An example -

Not long ago I advocated the use of lucene for an intranet search engine to a company, after having been told about the profile of their IT department. Gosh, we even had to read them the manual pages at the phone. It turned out that the Java expertise rested on the shoulders of some few overladen with work. Now I'm the bad guy which gave wrong counsel.

And so on. A decision matrix would be handy.

Templating is well-covered, and the modules out there are quite evolved and mature, and that is just their^H^H^H^H^Hmy problem. TIMTOWTDY is fine, but it is lost in the process of evolving and maturing of those bundles. I am supposed to inherit from Class::Prototyped in one, and from Class::NEXT in the other. What if I want to use Spiffy?

No, I wouldn't say it doesn't matter lest I do decisions which I would later regret and get stuck with obscure bugs trying to get features work which I definitely must have, and which might be well a "bug by design" - and having to deal with included code which I must "trust" because I don't understand it - and I don't understand it because I don't have the time to walk it's guts (well, that holds for perl as a whole, but here the situation is different: when I first worked with it, it was version 4 patchlevel 36, and at that time I trusted it because I was naive. Now I trust it by experience and because it's seasoned :-). Quote from above report:

In the meantime, I seem to have a workaround – I just undef $template->{driver} in my scripts prior to $template going out of scope. It's an ugly solution, but I'm trying to avoid switching to TT as we have too many templates to change at the moment, and I think the HTML designers would throttle me if I introduced a new template system to them.

Bottom line: rather than a complex toolkit I would have small modules with the least inheritance possible, which address each a well defined problem, having defined and agreed-upon interfaces and a complete documentation. I'm still adept to the old UNIX philosophy of small is beautiful which led to specific tools for specific purposes that can be combined following rather simple rules, and I would use those rather than an "all-in-one device suitable for every purpose", philosophy of some wicked company which does e.g. office software (heh, I'm trolling for baits :-).

Speaking of MVC (which seems to be a paradigma widely adopted for web programming) I would rather see Web::Model, Web::View, Web::Controller and Web::Engine or such than any of them toolkits. Then it would be about time to subclass with e.g. Web::Controller:DBI or Web::Controller::CGI. All other approaches seem cruft to me (at the current state of my garlic).

That said, although my posted code is crufty and never was a module for release I don't think its ideas must be thrown away (mainly because they're already done).

One more word - the "don't do that, it's already done" argument doesn't make much sense. If it were for that we would never have seen SysV or Linux, but would be all happy using *BSD.

greetings,
shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

All of your points cover the code you write too, except possibly for the intimate understanding of the guts of the code. Thus I cancelled them out in the equation.

My core business isn't writing a templating system. It's writing and editing technical documentation. Thus it's a risk for me to write a templating system. However, part of producing technical documentation is managing and presenting and encoding and formatting text appropriately, so when it came time to produce attractive, well-formatted output, I faced a problem in which (I still believe) creating my own translation utility was the right solution, even though others exist.

I don't particularly want to support it (I wish someone else did), but I understand it and now it exists and I can add features if and when I need them. However, a short period of time into my experiment revealed that I really don't want to write, port, or refine a linebreaking algorithm. Thus I rely on someone else's. It's not perfect, but I have confidence that building on that core will be much easier than reinventing that work.

It's just a matter of what's important. It's really difficult for me to believe that, over time, building your own mini templating system will really pay off. I could be wrong. Like I said, it's not my decision and I definitely know very little about your environment... but I do like to think I understand some of the risks of writing and maintaining software.