Is this an impossible mission?

Pretty much. People choose the different modules because they do different things. You're just not going to be able to switch the average Template client code to HTML::Template, just like you're not going to be able to interpret Petal templates with Mason. Their design/usage goals just don't match up in the same way that different databases do.

However, you may get something like what you want with TT3, which is shaping up to be a meta-templating system that you can use to build templating systems with with - so you'll end up sharing more code.

Aha TT3 sounds interesting. But as long we have the other 999 CPAN templating engines we will have different preferences.

May be one could minimize everything to a very very small core. May be that would be usefull and people could improve it?

I do not see why your arguments weren't the same for DBI/DBD which was a hit. When DBI/DBD did an API unification job, then "TPI" has also good chances? Or would we need something like SQL for template engines?

Murat

May be one could minimize everything to a very very small core.

If you did that, you'd essentially come up with HTML::Template. People have obviously decided that, for whatever reason, HTML::Template doesn't solve their problems and have looked elsewhere.

I do not see why your arguments weren't the same for DBI/DBD which was a hit.

Even though various relational databases do the details differently, their conceptual functionality is the same, and they even use the same query language (more or less) to get the job done. Further, Cobb laid down the basic functionality an RDBMS must provide. The abstraction is straightforward (even if the implementation is difficult).

Although you could make the decision that a template system should generate a defined output for a given input, the details of how this is acomplished vary so widely that I doubt it would work. It would have to be so far abstracted from the real template system that nobody except HTML::Template users would be happy with it. (Which is a long, rambling way of getting back to my first point).

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

Aha TT3 sounds interesting. But as long we have the other 999 CPAN templating engines we will have different preferences.

If TT3 lives up to its initial promise you'll have a system that can be used to implement all of those 999 CPAN templating engines. A system that will allow you to share common elements (e.g. caching mechanisms) while still taking advantage of whichever template style you find most useful.

May be one could minimize everything to a very very small core. May be that would be usefull and people could improve it?

Then you will essentially end up with HTML::Template. Which is nice, but doesn't meet everyone's needs. One of the reason there are different templating systems is that they do different things in (usefully) different ways. Somebody who builds their application with TT2 templates and plugins will have a completely different structure from somebody building their application with HTML::Template which would, in turn, be different from somebody building an application with AxKit.

You can, of course, have long and interesting arguments about which would be the best model for an application. However there isn't any way you can map a series of transformations in the AxKit style, or something written using TT2s plugins and template language, back to HTML::Template.

With a unified system the lowest common denominator is going to be too low to be useful to many people.

I do not see why your arguments weren't the same for DBI/DBD which was a hit. When DBI/DBD did an API unification job, then "TPI" has also good chances? Or would we need something like SQL for template engines?

The main reason it's different is that DBI/DBD has a single powerful model that unifies all the data sources that it talks to - the relational data model of tables and columns queried with SQL.

I don't pick databases because of the relational model - it's a given. I want to do the same sort of operations to an SQLite database as I do with an Oracle database so it makes sense to have a common way of communicating with them.

When you use DBI to look at things that aren't RDBMs, like Excel spreadsheets, it's because you want to leverage the power of that relational model.

You don't see DBI interfaces to XML based databases, or OODBs, or Prevalence style persistence layers because the conceptual model is different. The reason you would choose an OODB or a Prevalence persistence layer is because you don't want a relational model - so DBI would make no sense.

The same is true of template systems. I pick TT2 over HTML::Template or HTML::Template over AxKit because they have different ways of approaching the world. There can't be a common interface because their models are fundamentally different. Having an interface to TT2 that also worked with HTML::Template would remove the reason I would use TT2 in the first place.

• HTML::Template is designed to do one thing - be fast. Be very, very fast. It has extremely few things it can do, but it does those things very well. It's a mark of how well samtregar designed it that it's used in as many places and in as many ways as it is.
• Template Toolkit is designed to do one thing - be very easy to work with. And, it does this very well. It renders very fast, but that's not its primary goal. It's primary goal is ease of abstraction. And, it does this very well.
• Mason isn't designed to be a templating system. It's a Content Management System, similar to Asgard and many others. It's a mark of its strong design that it can be used solely as a templating system. And, like the others, it does CMS very well.

You can't even abstract out common functionality. I'm in the process of looking to convert my apps from H::T to TT because I need the additional functionality. (Most apps will never need this functionality.) I'm finding that the very code I'll be using to generate the data structures for TT is going to be different than the code used for H::T. In many cases, up to 80% different.

This isn't an indictment of H::T. In fact, when I first started work on these apps, I knew I would convert to TT at some point. I used H::T for its strenth - speed of initial development. I know it inside and out. I could throw it out there and not worry about it.

TT, on the other hand, requires a lot of thought and up-front design. I didn't know enough about what I would want, nor could I gather that information in the initial 6 weeks I was given to make everything work. Now, I do know enough, so I can do my design and convert my apps.

Mason isn't designed to be a templating system. It's a Content Management System, similar to Asgard and many others. It's a mark of its strong design that it can be used solely as a templating system. And, like the others, it does CMS very well.

I don't understand this statement at all. Mason is very much not a CMS! A CMS is an application. For example, Bricolage is a CMS.

Mason is a templating system plus an application framework, mixed together, which is where it differs from HTML::Template or TT. For example, with Mason, you can plug it directly into mod_perl without writing any code but Mason components. You don't need to write code to marshall your data and pass it into Mason.

In other words, Mason is entirely self-contained. Of course, it doesn't have to be used that way. David Wheeler's MasonX::Interp::WithCallbacks module lets you do some processing before Mason steps in. I'm also working on something similar(-ish) that works with Mason. There's also Mason support for Maypole now, too. So you're certainly not obligated to use Mason and only Mason for an app.

I apologize - I have only read bits and pieces on Mason and I remember reading where it describes itself as a CMS. (No, I don't have the citation. Sorry.)

However, your statements help illustrate the basic thrust of my point - Mason isn't a templating system, at its heart. It's an application framework. You write a Mason app, not a Perl webapp. That Mason is in Perl and you can use Perl is kinda secondary. It would be like writing an app in Oracle's AppServer. You'll be using some SQL and PL/SQL, but that's not the main thrust of the thing.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

Hugh, i am really overwhelmed by the negative comments. Seems like the idea is somehow insane. May be i am to primitive when thinking about templates.
But why do they all have the "template" in their name. I am sure they must have something in common.

Initially one could ignore all the superpowers of TT's and ??'s and concentrate on the core "beeing a template" thing.


Something on CPAN already?

Murat

If you want the training wheels without the bike, you can start with the lowest common denominator, but that will compell nobody to switch from their templating system to your backend system.

For most people, their templating system "just works", and depending on the application, one templating system is more suited than the other. But you don't gain much benefit of making the templating frontend interchangeable, as people usually don't switch templates, and even if switching templates, any such switch will involve changes in the driving software anyway.

The only thing that could possibly be saved would be that one doesn't have to install yet-another-templating-package just to support the new templating syntax, but if an application switches its templating system, that's a minor point anyway.

DBI is different, because it makes the backend exchangeable for an unchanged frontend. Your abstract templating idea tries to make the frontend and input data exchangeable, but changing the frontend and structure of the input data is not something you do on a whim or have as difference between development and produciton environment.

You can compare an SQL statement to a template, and the DBD is the templating engine. But with DBI, you feed it always the same statement, only the transformation for the backend differs. With your solution, you feed it different input to create the same output - this sounds more like different programs than something that should be solved by plugins.

You are very naive in your thinking about templates. Yes, they do have a very basic function in common, which is to take a layout and a set of variables and produce something with those two things. However, templating is a much more complex task than communicating with a database (which isn't trivial).

I wrote and maintain PDF::Template, Excel::Template, and Graph::Template. They're designed to work with HTML::Template. When I started looking at TT, I wanted to reuse those modules. Then, I realized that what I was trying to do was hopeless. The data structures used are so different and the expectations of the client are different.

Now, TT may be what you're looking to use. It is an attempt to make using templates very generic and extensible. H::T was written a long time before Template Toolkit. (Correct me if I'm wrong, but wasn't TT a response to H::T's deliberate lack of features?) Just because it isn't the DBI of templates doesn't mean it doesn't do what you need. And, there's a book on it, too! :-)

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I think the biggest reason is simply because each of the available templating systems is nowhere close in likeness to any of the others. With the databases, most of the drivers behave similarly since most database systems run similarly. Having a simple interface to each of the templating modules just wouldn't work very well... just try to make the more advanced Template features work with HTML::Template... it just wouldn't scale.

Hey,

they all have a core functionality in common.

define variables -> open template -> interpolate -> output
I.e. web developers could intermix the preferred template language within site-wide. The just shebang the correct TPD and viola!

I love the idea.
Murat

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.

Here's a quick sketch how this could look like:

#!/usr/bin/perl -w

use strict;

{
    package MetaTemplate::TT;
    use base qw(Template);
}

{
    package MetaTemplate::HTML_Template;
    use HTML::Template;
    sub new {
    my $class = shift;
    bless {}, $class;
    }
    sub process {
    my($self, $input, $vars, $output) = @_;
    my @ht_args;
    if (ref $input eq 'SCALAR') {
        @ht_args = (scalarref => $input);
    } else {
        @ht_args = (filename => $input);
    }
    my $ht = HTML::Template->new(@ht_args);
    if ($vars) {
        while(my($k,$v) = each %$vars) {
        $ht->param($k => $v);
        }
    }
    my $o = $ht->output;
    if (ref $output eq 'SCALAR') {
        $$output = $o;
    } elsif (defined $output) {
        open(my $OUT, "> $output") or die $!;
        print $OUT $o;
    } else {
        print $o;
    }
    }
}

{
    package MetaTemplate::Text_ScriptTemplate;
    use Text::ScriptTemplate;
    sub new {
    my $class = shift;
    bless {}, $class;
    }
    sub process {
    my($self, $input, $vars, $output) = @_;
    my $tmpl = Text::ScriptTemplate->new;
    if (ref $input eq 'SCALAR') {
        $tmpl->pack($$input);
    } else {
        $tmpl->load($input);
    }
    if ($vars) {
        $tmpl->setq(%$vars);
    }
    my $o = $tmpl->fill;
    if (ref $output eq 'SCALAR') {
        $$output = $o;
    } elsif (defined $output) {
        open(my $OUT, "> $output") or die $!;
        print $OUT $o;
    } else {
        print $o;
    }
    }
}


my $t1 = MetaTemplate::TT->new;
$t1->process(\<<EOF, { answer => 42 });
The answer is [% answer %].
EOF

my $t2 = MetaTemplate::HTML_Template->new;
$t2->process(\<<EOF, { answer => 42 });
The answer is <TMPL_VAR NAME=answer>.
EOF

my $t3 = MetaTemplate::Text_ScriptTemplate->new;
$t3->process(\<<'EOF', { answer => 42 });
The answer is <%=$answer%>.
EOF
[download]

Bingo!

Of course one could think more about the API, but i love it already. It is really what i had in mind.

For maximum flexibility one could add shebang detection:

    my $tpi = TPI->new( dsn => 'tpd:Mason:/my/files/' );

    $tpi->register( 'TPD::HTML_Mason', shebang => '#!mason' );
    $tpi->register( 'TPD::TT', shebang => '#!tt' );
    $tpi->register( 'TPD::HTML_Template', shebang => '#!htmpl' );
    $tpi->register( 'TPD::PETAL', shebang => '#!petal' );
 
    $tpi->variables( author => 'a', title => 'b' );

    print $tpi->interpolate( <<'END_HERE' );
#!mason

Welcome <% $author %>
END_HERE

    print $tpi->interpolate( <<'END_HERE' );
#!htmpl

Welcome <TMPL_VAR author>
END_HERE
[download]

Of course the TPD driver could translate ie. looop variables n'stuff.

I am convinced that ~90% demand nothing more than the basic functionality from the templating engine. And so one could unify all the tons of api to just TPI.


I am convinced this would be fastly adopted/standard as DBI.

Anybody setting up a ml?

Murat

I think if you wait for TT3 (the heir apparent to TT2), you'll find that it does most of what you want. A core of abstraction of the parts of a templating engine, with skins that can be added to mimic most existing systems.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Update: Perhaps I am answering the wrong question. Were you meaning why is it that no one has a basic Templating interface, able to hook into the many templating modules?

-enlil

You update is hitting it: porting just the concept. Murat

The Template Toolkit has a nice tutorial on their web site (from TPC4), and I'm also midway through a three part tutorial for my Linux Magazine column, although you can't read the articles until the embargo is lifted.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Actually, it would just confuse the newbie and keep them at the idiot's level. Better is to hit your learning curve and learn a templating system. The simplest to learn is HTML::Template.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose