princepawn sez:

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.