Mark Thomas wrote on the subject of templates written in XML:
> I can think of two ways to do it: alternate namespace (convenient for
> XHTML):
[ cross-posted to TT3 list because I'm rambling off the subject into
aspects of TT3 design ]
One of the important features that I've added in TT3 is a separation
of the scanner from the parser. This should make it possible to have
an XML parser scanning an XML document, identifying the TT tags or
attributes, and then calling the appropriate parser handler methods
to construct the compiled template. Very much in the style of
XML::SAX, but for templates.
The idea is that TT3 should provide a more general platform for
many different kinds of templates: TT2, TT3, XML TAL, and so on.
Rather than relying on my idea of what a template language should
be, you should be able to plugin in a different language or even
roll your own for a particular application. If you can reuse the
remaining 90% of the TT backend and have runtime compatability between
templates written in different markup languages then the whole issue
of which template language is the "best" becomes far less important.
You can use whichever is most appropriate to the task at hand.
I'm aiming for something like this:
my $tt = Template->new({
templates_path => [
# define language based on location...
'/home/abw/templates/tt2' => { language => 'tt2' },
'/home/abw/templates/tt3' => { language => 'tt3' },
'/home/abw/templates/xml' => { language => 'ttxml' },
'/home/abw/templates/mason' => { language => 'mason' },
# or based on a file extension...
'/home/abw/templates/misc' => {
extensions => {
tt2 => { language => 'tt2' },
tt3 => { language => 'tt3' },
xml => { language => 'ttxml' },
},
},
],
});
Well, that's what I'm aiming for but, but of course, the devil is in the
details. There are still some issues to finalise, but the code is in the
process of congealing right now.
A
|
