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,
Dave
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 plugin. -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 http://vanabel.com http://perlsources.com 303-249-3855 Yahoo Instant Messenger = dave_vanabel
