Why do you want to replace HTML::Mason? Any shortcomings or specific flaws, or you just find Template Toolkit more powerful?

The doc for Template Toolkit is quite... short and I really can't figure out what it does.

In short, since I just had this discussion yesterday:
• TT is language-agnostic, and works well even in languages where whitespace matters.
• TT provides heavy customization callbacks at each level of processing
• TT has an embedded language that hides the difference between hashes and method calls so dumb hashes can be turned into smart objects later
• TT plays well outside mod_perl as a static transformation tool (or even in CGI)
• Mason has better "out of the box" caching, but TT has all the right hooks to write your own easily, probably better for real applications anyway
• TT permits Embedded Perl to be turned off or on for a given input source, useful in an enviroment where full Perl interface would be dangerous or misleading
• embedded TT triggers can be changed to suit the parsed language, and for HTML be selected so as to get into and out of WYSIWYG HTML wranglers without mangling
• One customer site I know doing $30M a year is using it and recommended it highly over the other embedded Perl/HTML solutions after doing their own study

-- Randal L. Schwartz, Perl hacker

Some of this post is corroboration of merylyn's post, some parts are rebuttle. I think the bottom line is that no-one has completed an empirical comparison of the all the major web application development frameworks for Perl. I have listed all of them on my home node, they are:
1. chromatic has an attempt to develop an application server for Perl similar to Zope, but it is not really in release stage yet.
2. There is something called Iajutsu which is enormously complicated but uses the Template Toolkit for its templating.
3. BingoX - developed by two former eToys consultants (merlyn told me this), adds Mason-esque features to Template Toolkit. on sourceforge somewhere
4. Html::Embperl - my tool of choice. Similar to Mason but with more facilities for rapid page development. Ie, expansion of arrays into tables, automatic creation of hidden fields for data posted from previous pages, per-page, per-user, and per-session data hashes, and more.

   And regarding playing well outside mod_perl, Embperl works in CGI, offline, or mod_perl enabled modes. So no advantage to cpan://Template] there.

   And finally, his companion (but useable separately tool) DBIx::Recordset has many niceties for HTML-based database navigation and for commission of form data into database in one -line.

5. HTML::Mason - very popular in the US. Excellent cache support. No offline HTML generation
6. HTML::EP by Jochem Wiedman, also has database support in addition to a full-range of features similar to Embperl.

Regarding Template, one must observe that it is middle-of-the-road. That is, on one hand, the conservative hand, we have HTML::Template which only allows one to place variables in HTML and thus demands maximum code re-use should you want to throw away your old HTML. On the other hand, the liberal hand, we have HTML::Embperl, where you can place Perl code right inside your HTML. In this case, you may not get around to creating abstractions and may not get the code-reuse the HTML::Template offers. But, it does offer abstraction mechanisms. You can create HTML::Subs which are like Perl subs, only their default language is HTML and you must escape to do Perl processing. Example:

[$ sub favorite_tag $]
<h1>Python is for weenies</h1>
[+ $date = (localtime)[3] $]
<h1> [+ $date +]</h1>

<li> [+ favorite_tag +]
[download]

And then of course, we have smack-dab in the middle, Template, the Template Toolkit. It allows you to play the conservative game and only inline Perl variables. But its %% PERL %% tag allows you to get as butt-wild as cpan::HTML::Embperl if you feel like it to.

So, really, it is high-time that someone assess these modules based on full-blown development instead of all of the piecemeal arguments and flame wars that I have seen to date.