Clear questions and runnable code
get the best and fastest answer
Re: Re: I am about to write my very own templating module..by Arguile (Hermit)
|on Sep 26, 2001 at 14:48 UTC||Need Help??|
"... HTML::Template... which will let you create templates that look more like some code source than HTML." If you're saying this then I really don't think you properly evaluated this module.
HTML::Template consists of only a few control tags (loop, if, else, unless, include). There aren't any "commands in arbitrary places" as inline perl is not allowed. It has a very simplistic control structure; to illustrate this, let's look at a sample template.
Those of you familiar with HTML::Template (but not filters) will note my template doesn't look like the examples in the POD. We'll get to that in a moment.
The above contains variable interpolation, an if-then-else statement and a nested loop structure that combine to create a table. The previous sentence is more complex than the template. And this is a good thing.
Even to an incredibly dense web designer (oops, that's redundant ;) this template shouldn't take too long to explain using a good example. To make things even easier on them and, in so doing, ourselves -- we can add the tags to their WYSIWYG tools. It took me 30min and a visit to Macromedia's online documentation to add 'drag and drop' tags and their accompanying editor widgets to Dreamweaver.
Now I like this syntax, but maybe you don't. I don't like the default module syntax, maybe you do. That's okay. HTML::Template allows us all to have our own way through pre-processing filters. By passing the module a filter (sub ref or array of subs refs) you can regexp or otherwise process the template before it gets passed to HTML::Template proper. In this way you can do all sorts of fun things like change the syntax to whatever you desire. Performance is not an issue in this case unless you write horrible horrible regexps.
Look Ma! No HTML! None. At all. Anywhere. Wonderful no?
Now it looks a little messy when hard coding the variables, but when you consider that you can associate the param() method with CGI's (or any other than functions like it) and that you can fetchrow_hashref (or create your own) from a DBI query...
My example is rather trivial, but you might be suprised at the power such a simple templating system has. If you subscribe to HTML and Perl in seperation, as you seem to do, then this module is the epitome of that philosophy.
Before you go off and write another new system be sure to take a long hard look at the current systems. You'll probably find one that's close enough to your philosphy that you can either adapt it through something like filters, or maybe even take an active hand and contribute to it.
I'm writing this at 3:30am. ;)
I'm biased. I ascribe heavily to the philosophy behind HTML::Template and TT2. TT2 often gets a lot of evangalism though, so I chose to focus on HTML::Template. If I had to choose one, I think TT2 would win out; as "you get enough rope to hang yourself and half of the town with you" (mirod) whereas HTML::Template can keep you a bit to tight a leash at times. As always YMMV and CTRTFTJ (Choose the Right Tool for the Job).
I focused mainly on philosophy and syntax. There are lots of documents dealing with speed and fine tuning when you get to that point. Often people concentrate too much on that factor when your, my, and the graphic artist's workflow matter much more (in most cases)