Re: I am about to write my very own templating module..

The fact that TT2 or HTML::Template support elaborate constructs doesn't mean that you have to use them. You can perfectly decide not to use anything else than simple variable interpolation and loops. This is really the core of the Perl spirit by the way: you get enough rope to hang yourself and half of the town with you, but you can decide not to use it. Perl let you decide how to use the language, advanced templating systems let you decide how much you want to put in the template.

I personally use Text::Template, and I mostly use interpolation and loops like foreach (@item) { $OUT .= "<td>$_</td>"; }.

That said, if you want to improve a module so looping over complex data structures becomes easier, by all means go for it!

Here is an example of a function for Text::Template, that will return a list as an HTML line. You could write a bunch of those functions, then have them loaded from a separate file through prepend or always_prepend.

#!/bin/perl -w
use strict;
use Text::Template;

@T::list= qw( foo bar baz);

my $template = new Text::Template (TYPE => 'FILEHANDLE', SOURCE => \*D
+ATA );
print $template->fill_in( PACKAGE => 'T');


  
__DATA__
{sub table_line
  { $OUT .= "<tr>";
    foreach (@_) { $OUT .= "<td>$_</td>"; }
    $OUT .= "</tr>";
  }
}

simple list:{table_line( @list);}
[download]

This is just a (probably lame!) example, but I just want to stress that writing Yet Another Module might look glamourous, but if you want your code to be really useful (and used), modifying an existing module might be a better idea.

Comment on Re: I am about to write my very own templating module.. Select or Download Code

Replies are listed 'Best First'.
Re: Re: I am about to write my very own templating module.. by ajt (Prior) on Sep 26, 2001 at 13:33 UTC
I have a great deal of sympathy with Screemer on this one. Both Perrin and Mirod have valid points, but conceptually there are problems with all the current templating methods. I use to work for a company that helped to invent DOM and XML. We built quite a clever HTML/XML templating engine built around XPath/XPointer and DOM. Problem was the code was spagetti, and we built much of it before we submitted proposals to the W3C, so it was a bit pre-standards. The key thing about the templating method, and the thing I still like about it most, was that the source and template were both XML. Basically the engine traversed the template XML DOM tree, and when it found an instruction, it pulled content via XPath from the content document, or via another script. The beauty of this approach is that the template and source are well-formed XML/HTML that can be worked on with any respectable HTML/XML tool. The templating engine just did templating and not much else, and "smarts" are independent from both the templating engine and the souce/template files. I am not able to use this tool in my current role as it was built in a proprietary BASIC like language, in a server plug-in to servers other than Apache. I know I'm a heretic for doing this, but I built my own templating engine in Perl, using CGI and Perl. It's 600 lines of Perl, including comments and POD. It works real well. It uses as many modules as I could find to keep the bits I wrote as short and simple as possible. At the moment I'm trying to tease it to work on mod_Perl, where it will be fast enough to use in a small multi-user environment. I contacted various people, and got good feedback from several template authors, but their templating methods just were not what I was looing for, though TT2 came closest. Here is how it works....... Request comes into Apache Apache starts the script The engine checks to see if there is a finished page in the cache, and serves that if there is one The engine loads the template, and scans it When it finds an instruction, if goes off and pulls that content in Finally it caches the page, and sends the finishined page to the browser The engine understands requests to get files via HTTP, FTP, or from the local file system. When it has got a file, it can use HTTP::TreeBuilder, XML::TreeBuilder or XML::XPath to extract a given fragment. So if you want to call a dynamic menu for example, you simply place a call in the template to a script (any language) that makes a dynamic navigation fragment, then you parse or grab verbaitim the bit you want. At the moment I pass all pages through HTML-Tidy to clean them up, but this is easy to configure if you want to change it. To publish the finished pages, I simply use GNU WGet to suck all the pages of the server, and then FTP them to a production server for final delivery. This solution is not fast, it's not supposed to be, but it's faster than I thought, and is getting faster. I probably could implement it in TT2, but as mod_Perl is flakey on NT/Apache yet (Re: Re: Re: (jeffa) Re: Good place to learn Apache::PerlRun), this isn't an option for me. I built a little ego site using this technology, and it performed perfectly. The site is a bit lame, so apologies to monks who look at it... I know I have gone against the advice of more learned monks... but sometimes you have to try something to learn, even if it turns out to be a mistake!	[reply]
Re: Re: Re: I am about to write my very own templating module.. by perrin (Chancellor) on Sep 27, 2001 at 08:49 UTC
I use to work for a company that helped to invent DOM and XML. So that was your fault? :) The key thing about the templating method, and the thing I still like about it most, was that the source and template were both XML. Sounds a lot like the things that AxKit can do to me, or possibly Apache::ASP with XMLSubs. The beauty of this approach is that the template and source are well-formed XML/HTML that can be worked on with any respectable HTML/XML tool. If that's important to you, you could check out HTML_Tree as well. Request comes into Apache Apache starts the script The engine checks to see if there is a finished page in the cache, and serves that if there is one The engine loads the template, and scans it When it finds an instruction, if goes off and pulls that content in Finally it caches the page, and sends the finishined page to the browser Strictly speaking, caching pages is more of a web framework function than a templating tool one. Personally, I like to use mod_proxy for this and take some load off mod_perl. However, AxKit does have this built in.	[reply]