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

if you can install one module, why can't you install 20?

Simply due to convenience and cleanliness. Imagine what a cgi-bin looks like after you install four of five scripts which all require their own set of 30 external files. Even if the extra files go into subdirectories, it looks a lot better, but it doesn't look good. I'd really like to telnet in and do 'su -c perl -MCPAN (..)', believe me. :-/ But I do not have that convenience in this case, and even if I did, others might not, in case I release the script. Requiring a specific multilevel directory tree to place the modules in is going to make installation for less adept users painful also. So the fewer extra files I can get away with, the better. HTML::Template is perfect in that regard, a single file that I can rename and then manually require/import if need be.

But no one is twisting your arm and telling you to use the full syntax of TT! Just use the part you want.

I would - but again, see above paragraph.

I started out really simple, but I ended up with a mess because people kept requesting features like columnizing lists, or slightly fancier boolean conditionals, or date formatting, etc. That's why I get so suspicious when people complain that the existing modules have too many features.

I am aware of that trap and am not going to fall for it. I want the interpolation to provide enough flexibility to implement these features on the template's end (rather than the templating module's) without the template language providing elaborate control constructs and that should be doable with a fancy variable dereferencing syntax.

The closest to what you are suggesting is Text::Template, but I don't know how easy it would be to extend.

I will have a look.

So far I fetched HTML::Template and found that getting it to comply to my wishes is very possible by just wrapping a layer of own routines around it. Basically I lie to the module about my data and feed it through the back door; the main dirty trick is that I use the association mechanism to make it think that [foo.bar] is an actual variable while my param() silently derefences that into $t->{foo}->{bar}. Anything but conceptually clean - but it works well.

Edit: I had a look at Text::Template - that doesn't at all seem to be like what I want. It uses Perl embedded into templates, whereas I want an absolutely minimalistic minilanguage. Am I missing something?

  • Comment on Re^4: I am about to write my very own templating module..

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: I am about to write my very own templating module..
by perrin (Chancellor) on Sep 27, 2001 at 08:29 UTC
    Not Text::Template, Text::Templar.

    For personal use, I would suggest simply making a ~/perl-lib directory and installing all of your CPAN modules there, but if your intention is to distribute this to people who are not sophisticated Perl users I could see how that might be a problem. Ultimately though, you could still just package up all the files into one big .tgz and then use relative paths to require all libraries (with FindBin or something).

      Ouch, I thought "Templar" was a typo. I have to say "wow" - this one does really look extraordinarily good. If it just didn't require a boatload of other modules along with Perl 5.6 .. :(

      I'm definitely keeping it for possible future use though! Thanks for the pointer.