The Template Toolkit is a fast, powerful and easily extensible template processing system written in Perl. It is ideally suited (but not limited) to the creation of static and dynamic web content. It is robust, reliable, well documented and freely available as Open Source.

I've been using the TemplateToolkit for a few years now, and have been wholly converted to it. IMHO, it is heading toward being The Ultimate Templating System for perl. It allows for a very clean separation between logic and presentation via hash namespaces used in populating the templates. And although extremely flexible out of the box, the system is completely extensible via plugins which add new capabilities into the template environment, provide tags to define filter blocks in which content is processed through code.

There is even a very flexible architecture in how the system finds templates in the first place. The plain vanilia manner, or course, is to read them straight from file storage in a directory. However, one can supply new "Template provider" classes to allow the system to find, compile, and cache templates from database tables, from in-memory hashes, basically from any source you can wrap an object around.

And one more thing: The TemplateToolkit is not restricted to HTML, and can be used to generate any text document type. In fact, newer plugins look like generating templated images (ie. via GD image generation libraries) from the template namespace data.

-- LesOrchard - 01 Jun 2001

This has been throw around a bit. I've been looking at it myself, although last time I fiddled with TemplateToolkit was 12 months ago. I'm not sure what the state of the are is now.

The main thing to consider I see, is defining a clear path for the TWiki syntax rendering to be understood by TemplateToolkit. If it can be done without forcing a change in the syntax defined TextFormattingRules that would be great.

-- NicholasLee - 04 Jun 2001

Basically, the TextFormattingRules could stay the same. TemplateToolkit has a facility for defining filter tags. So, wherever in a TWiki template that content following the TextFormattingRules appears might look something like:

[% FILTER TWikiFilter %]
  $content
[% END %]

...where $content contains the text of the content, of course. The implementation of a filter plugin is basically some plugin boilerplate surrounding a single sub into which the text inside the [% FILTER %] construct is passed, and the filtered text returned. So, all the regexes implementing the TextFormattingRules could be collected there.

The only things one might want to have different are things like how TWikiVariables are included and the other miscellaneous little constructs and function calls in the %...% syntax. They could just be implemented along site the other formatting rules in the filter, but here one might want to take advantage of TemplateToolkit features here.

For instance, TemplateToolkit does a very good job of managing access to variables and objects in the template namespace. Plain variables can just be thrown into the namespace hash. So instead of % SERVERTIME%, it would be $SERVERTIME. Or, one could organize all the variables under another namespace key, so maybe $TWiki.SERVERTIME.

As for the programmatic elements, such as % INCLUDE{...}%, TemplateToolkit also allows access to plugin object methods. So, maybe create a TWiki utility object with a method include. % INCLUDE{..}% could turn into $TWiki.include('filename'). And, in this way, new TWiki functions could be added simply as methods to the hypothetical TWiki utility plugin object. No mussing with regexes to parse all the arguments, etc...

And on top of all of this, you get basic conditional and looping constructs, and only as much system level access as your plugins allow. So, no opening files unless you supply a file access plugin, etc...

-- LesOrchard - 05 Jun 2001

How about turning off access to certain features of TT within the main content body. ie. Otherwise we might create a security hole.

-- NicholasLee - 06 Jun 2001

The toolkit is very powerful and can also be extended with plugins, i.e. the tutorial mentions a DB plugin where you can specify a SQL query and loop through the rows to display the result.

This is all nice but it probably is not a good fit for TWiki:

• The TemplateToolkit is BIG, only the lib directory is over 1 MB. That would mean an increased CPU load and memory load for each topic view.
• The TWiki core should stay lean and not depend on too many external modules. (Plugins are excluded)
• There is an overlap of functionality of the TemplateToolkit and TWiki, i.e. the plugin.
• The syntax is (not surprisingly) not a good fit.

As mentioned in CommonHeaderFooterTemplate it makes sense to define common patterns just once, i.e. the header and the footer so that it is easy to change them. Since the TemplateToolkit is not suitable we should roll our own TWikiTemplatingSystem.

-- PeterThoeny - 21 Jul 2001

Further discussion refactored to BetterTemplateSystem