You obviously haven't used more than one templating system. HTML::Template works along the pipeline you describe. Petal, HTML::Mason and Template Toolkit allow various forms of callbacks, all with different notions and notations.

The notations could possibly be abstracted away for a backend, but you need something like HTML::Template::Expr, if you want callbacks in HTML::Template - and samtregar has stated it on more than one occassion that such stuff is outside the scope of HTML::Template.

Letting web developers use different template languages within one site is a sure recipe for disaster - it's akin to liberally allowing use of Inline::C and Inline::Assembler within a project - you instantly lose the capability to let one person work on another page.

I think it's far more important to have a meta templating system for "end user" applications. For example, lately I was searching for a wiki system. I rejected all systems which did not use Template Toolkit (because this is the only templating system I can handle). Things would look different if there was a meta template module.

And it's not strictly necessary to support all possible features. Conditionals, looping and variable substitution should be enough, everything else being optional, but still accessible via the meta template module if the underlying system supports it.

I fear you have the same counter-arguments that Tim Bunce suffered when he proposed DBI/DBD.


I know HTML::Mason, AxKit, HTML::Template extremly well. Eventhough they are extremly different i am aware that they really have a lot in common.


Once it is there it will convince. DBI was a new era. I just remember that many serious projects were founded by people who just wanna had fun. So it comes that they are often reluctant to learn a new API/Template engine. They have their preference and that is good so. Let them all use THEIR DBD::<template engine>.


Murat