1. Your post reinforces what pg said in his preamble that most people are developing in 2 layers. I myself am doing the same thing right now for a gaming site whose max users will be around 50. I think what pg is saying is that more complex sites require more layers if they are to be understood and maintained.

Geez, I thought I was developing in 3 layers:

1. Business Logic
2. Display Logic
3. Application Logic

What I got out of pg's post is that he split his business logic into domain specific chunks and then presented a unified interface for those different chunks to his application and display layers.

Given that several different systems embody his business rules, I find his design approach totally appropriate.

2. Can you itemize a specific list of advantages that Template Toolkit has over HTML::Template? I would really be interested in seeing such a list. Because for me they are both similar: in-line mini-languages completely at odds with the HTML::Seamstress approach.

Full support (so far as I know) for Perl objects makes the biggest difference for me. I can pass Class::DBI objects to a template, call a method on it that returns a list and iterate over the list. With HTML::Template, I have to do that in in Perl along with the application logic. I nearly always end up dividing my code somehow into an application side (does work) and a display side (creates HTML). When my template changes, the display code changes. And though I have written display code that can drive any template I throw at it, I never found a clean way to do that.

I like Plugins. When I use a particular set of options (example. all the US states or all the countries in the world) for a select widget over and over again, I set up a singleton plugin object that returns a list of the options and pass the plugin along with the current value of the parameter to a standard template I made that builds HTML selects, for instance.

  [% USE us_states = US_States %]
  [% PROCESS include/select_tag options = us_states, value =  contact.
+us_state %]
[download]

I can use Filters to mutate my output. For instance I could build a PerlTidy filter (sounds obvious to me, I think one already exists), so that my application could clean up random perl code.

  [% USE PerlTidy %]
  [% snippet.perl_code() FILTER PerlTidy %]
[download]

In general, TT handles everything I throw at it in terms of display logic, so my application code stays focused.

"Business Logic" is not a layer. Your "Application logic" employs "business rules", but there is no "Business Logic".

. . . for me they are both similar: in-line mini-languages . . .

They are both in-line, but HTML::Template takes the view that HTML designers are not programmers, nor should they be. As such, the only control a template writer has over the output is simple conditionals, loops, and variables. Ignoring, of course, HTML::Template::Expr, which hasn't been updated for over a year, is rather inefficient, and is generally considered an evil step-brother of HTML::Template.

OTOH, TT is practically a full-fledged language of its own.

OTOH, TT is practically a full-fledged language of its own.

A language targeted at the presentation side. Allowing the presentation folk to use a tool that's better suited to them than Perl (and can be customised to an even better fit by the addition of plugins and filters).

But then I like domain specific languages :-)

TT is practically a full-fledged language of its own

I consider that the downside of TT. Look at some of the awful things people do with it when they try to do complex things in the template. Apache::Template is commonly a source of great evil. However, I think the majority of users are still treating it as a simple display-oriented language.