Thks for your candid comments. It appears TT or HT would do fine.

Fortunately for me, I don't have to deal with the project wanting to use TT & Mod Perl. But ...

I reviewed the existing code, and 90% uses strict and remainder doesn't. However, code with strict even violates some of the needs to pass info to a sub-routine and back out. This, in my experience, is what has made using mod-perl challenging!

If one site, on same server, invokes mod perl, I worry about the other site (which I took over development on), inadvently passing someone's credit card number to someone else some day, because of weak code (written in 3rd world). Stuff can happen.

In summarizing, it is not whether TT or HT is best, it's the risk with mod perl on weak code.

Your comments helped!

Thks again,


Brett Sanger wrote:
As I only use HT, can someone shed light on the pros & cons of using 
Template Toolkit?

Sure, I use CGI::App and TT now, having switched from H::T early on.  
(I stay on the list for the good discussion)

Pros to TT:  
-You don't have to write several filters to do anything
dynamic in the template.  
-You can write your own plugins to do program-type work, but let 
the designer decide when to use that plugin as opposed to requiring 
changes to the calling code.  Such plugins can be nice tiny, reusable
bits of code.

Cons to TT:
-As with anything powerful and flexible *cough*perl*cough*, it can be
done badly.  It's very easy to use template commands to start doing
programming in the templates rather than in the calling program or a
-Because it isn't "usually" associated with CGI::App or other organizing
code, the documentation, examples, and discussion don't show M-V-C or
other conceptual lines between programmer and designer.  (In fact, they
often show how to do monstrous contructions in the templates).  (There
are organizing codes that use it, [a fair number of CGI::App users,
Apache::Template, I think Bricolage accepts it, etc] but they aren't the
"normal" way).

Because the sort of work I'm doing would involve a number of filters and
repeated bits of code, TT was a very good match for me.  All the cons
can be avoided with some good coding practices and regular exposure to
places like this list where simplicity and cleanliness are repeated.  

I personnally don't care, except he wants to also use Mod Perl with 
sloppy code, and throw risks against the site I manage, when loading 
various DB modules.  Could go on, but life way too short for it.

If they have code samples for you to review you should get a good idea.
Good TT templates will (conceptually) resemble H::T templates:
displaying variables, running some loops, a number of IF statements.
Plugins will be used to genericize code bits that are shared between
templates and not always related to the purpose of the page.  (formating
a date, getting meta-information for the page, getting a list fo realted
pages, that sort of thing)

Bad TT code will be trying to program: DB accesses, deep conditionals
that don't cover design decisions, evaluating perl code.  

Of course, "good" and "bad" here is colored by my practices, so take
with the appropriate amount of salt.

Hope that helps

Dave Van Abel
Colorado, USA
Yahoo Instant Messenger = dave_vanabel