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".

The Anonymous Monk quoth:

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

Piffle. I don't know where you get that from.

Anything to do with how the business gets run gets coded in one set of class libraries.

Anything to do with an application program gets put in a separate class which asks the "Business Logic" nicely for a favor here and there:

Application Logic asks, "I got a guy here, wants to buy a widget ... what kinds we got, how many of each and what do they cost?"

"Business Logic" responds with the information requested.

Application Logic says, "this guy wants us to pay him to take a small green widget off our hands."

Business Logic replies, "I want some of the drugs he's on".

Get the difference between "Business Logic" and "Application Logic"? Business Logic holds across all applications, but the each application posesses its own logic.

"Business Logic" exists because I say it does, and it works for me to separate it into it's own layer.

. . . 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.

I've also seen people do truly awful things with HTML::Template. Because of the lack of expressive power in the templating language "view" related code migrates back into the controller/model, making it a complete pain to change the layout.

What it comes down to (as always :-) is getting vaguely bright people to do the project who understand how to separate concerns, and then using whatever tool does the job best - be it HTML::Template, Template Toolkit or whatever.

(I do agree about the evil people do with Apache::Template tho' :-)

perrin sez:

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.

Permit me to rephrase that: Apache::Template makes it damned hard to do anything other than display data. Which means that cruft sets in as soon as one tries to do more.

perrin's advice saved me from going down that path some time ago.