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

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

A long time ago the most interesting free Mason app was "the Mason CMS", which was used at CMP media, where Mason was originally written, IIRC.

You write a Mason app, not a Perl webapp.

Sort of. When I write a "Mason app", most of the logic is still in Perl modules. Mason is really just the frontend. It's just that app server bits it has built in make writing these frontends really simple.

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

TT started out as Text::MetaText quite some time ago (~1998?) and drew no inspiration from HTML::Template. In fact I was under the opposite impression, that HTML::Template was a response to the large TT :-)

Chris
M-x auto-bs-mode