Ronald J Kimball wrote: > I did an intro to Template::Toolkit...Uri Guttman gave an > informal presentation on his modules Template::Simple... > > This spurred a discussion on the benefits and drawbacks of putting > logic in the templates - Template::Toolkit allows a lot of logic > in the templates; Template::Simple requires all the logic to be in > the code.
It could be argued that a template containing logic is no longer a template - it's a program. I've used HTML::Template, Template::Toolkit (in use on a current project), and others, and have come to the conclusion that "mini languages are bad." (I've ran across some essays on this on Perl Monks.) I was reminded of this just a few days ago when trying to concatenate a string in a TT template and discovering that the normal Perl operator doesn't work (the reason why was pointed out in Ronald's presentation). Templating systems with mini-languages are convenient for developers, as they allow rapid construction of a view layer, but they also encourage bad programming practices - practices we often criticize in other web development environments like PHP, ASP, and Cold Fusion. But consider how much of your so called view layer would likely need to be redundantly implemented in a different set of templates if your site needed to support not only HTML but WAP or some other output format? There were comments in the audience about simpler templating systems necessitating view layer code polluting the controller layer. But if you actually examine the controller layer of a typical web application, you'll find that it is often doing view-layer specific manipulations of the data. They're not just fetching data and handing it to a page rendering method. It's a bit more work up front, but I contend that the better way to do this is to implement a view layer in your application language - presumably Perl. Then the programmers can use their "native" language to do any view-specific manipulations necessary, and operations common to multiple views can easily be put into shared classes. It was also interesting to hear the mixed audience response to the question of whether developers actually hand over templates to graphics (page) designers, or end up maintaining them themselves. I've read anecdotal accounts that although this capability was supposedly one of the (but not the only) motivations for using a templating system, such hand-offs rarely occur because the page designers aren't trained or trusted to work with the mini-languages, and/or the templating markup doesn't work with the page designer's tools (or validation tools, for that matter). If we're talking HTML templates, I'd consider the "holy grail" to be a templating system that uses pure HTML as the templating language (with standard ID and other attributes used to identify nodes of interest). The key to making this work is having a good library that provides an easy and concise syntax for manipulating HTML nodes (maybe XML::twig, XPath, or one of the DOM modules) with a layer on top that handles most typical cases of mapping data structures to templates, so template population is a one-line operation in the typical case. Such a system allows the page designer to create a real looking page populated with sample data. The template itself can act as a static demo of the final page. The shortcomings to this approach are included files and conditionals. Include files might be worked around by using IFRAME tags so the higher-level templates display with the correct included templates. (When processed by the template processor, the IFRAME's attributes would be examined, and if it was determined to be a template include, the IFRAME would get replaced by the rendered include template.) Conditionals, like displaying one of several error messages, can be a bit harder to deal with, but could use small templates in separate files, or embed all the choices in the template with CSS used to make all but the default choice invisible. (The page designer could temporarily make the other choices visible while working on the page.) You can argue that this approach just shifts the burden of learning a mini language to learning an API for manipulating HTML, and that's true, but learning a few basic node addressing APIs that combine using the already well familiar Perl operators and flow control is easier than learning a mini language that inconsistently emulates Perl. Of course keeping your executable code in Perl modules also has many other advantages. I think the main reason why we haven't seen a templating system like this is performance. In the early days of templating, it was just too painful to parse HTML (typically requiring a tokenizing parser), which led to the simpler templating tag systems that lend themselves to regular expression parsing. Today, with a move towards xHTML, which can be digested by compiled XML parsers, and techniques for "compiling" and caching parsed templates, I don't think performance is such an obstacle. Some "prior art": the disadvantages of mini-languages http://perlmonks.org/?node_id=428053 templating based on XPath http://www.perlmonks.org/index.pl?node_id=114766 rant on HTML::Mason, Embperl, Template, praise to HTML::Seamstress http://www.perlmonks.org/index.pl?node_id=124275 HTML::Seamstress - HTML::Tree subclass for HTML templating via tree rewriting http://search.cpan.org/search?mode=module&query=HTML%3A%3ASeamstress XMLC, A similar framework for Java http://xmlc.enhydra.org And a bunch more at: http://search.cpan.org/~tbone/HTML-Seamstress-4.26/lib/HTML/Seamstress.pod#SEE_ALSO I last looked at HTML::Seamstress in 2005, and at the time it had the low-level node manipulation stuff, but lacked the higher layer that made it convenient to map data to templates. It appears that it has since acquired this ability, as well as integration with Catalyst. It seems to require a bit more complicated setup than I'd like, but is probably the closest module to the "holy grail" I describe above. I haven't tried HTML::Seamstress, but I'd be curious to know if others have. It looks like it might now be in a usable state. > (Kenneth Graves commented, "There are a million places to put the > dividing line, and they're all wrong.") True, and the line varies relative to the scope of the project. On a project I'm working on now, which relies heavily on AJAX, I've proposed phasing out the server-side template processing entirely, in favor of client-side processing. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
