in reply to Re: I am about to write my very own templating module.. in thread I am about to write my very own templating module..
First of all, thanks for that article; it was a big shortcut in evaluating at least some of the available modules. Yes, I did read it - I am subscribed to the Perl.com Newsletter so I think I got to see it very soon. :)
HTML::Template and TT2 made it through my preevaluation. The final decision was taken mainly with respect to the fact that the script I'm writing is intended to work on a system with a barebone Perl5 and no way to install modules - as is the case with many cheap web hosts. HTML::Template only consists of a sinlge .pm - TT2 is no competition in this case.
Well then. I embarked in working with HTML::Template. But the syntax is not well readable - <img src="<tmpl_var imgfile>"> is bulky, the tag doesn't visually stand out against a page full of template HTML, and using the brackets within a tag irks me. There is no special case to deal with newlines around the <tmpl_*> tags, so you can't put them on a line of their own if you want the output to look neat and tidy. And <tmpl_unless> can get very tiring to write dozen of times.
The templating module I want would offer powerful interpolation syntax but not a bit more power in highlevel constructs than necessary. It seems there currently is no way to get one without the other. HTML::Template actually is the opposite of what I need, it offers relatively powerful highlevel constructs but only a very limiting interpolation syntax unless you enable globals in which case you end up with even harder to read templates.
I should mention that the processing model I want to implement is (by the terminology of that article) a very strict pipeline architecture that allows logic in templates by cleanly separating it back into the code: - fetch data, build list
- run filters over list to provide the template logic; variables get changed, added, deleted etc per record here
- interpolate data into template
All non-trivial modules I have seen try to integrate step 2 and 3 inside the template.
Now, you could say TT2 allows me to do it my way even if it offers more power than I want. But besides being awkward to use when you cannot install modules, to me it feels like "the tail wagging with the dog" as they say in Germany. Total overkill. I do not need a module that comes in 20-odd files incl XS, compiles my template to interpolate it, and can make coffee and bake cake to boot.
I was seriously about to go with CGI::FastTemplate - small, simple, clean concept written in a no-installation-required single Perl-only module. Except I had written something very similar myself for a previous (unspeakbly ugly) script and have come to despise the templatelet mess it reinforces. My only extra requirement beyond interpolation is just enough intelligence in the module so I don't end up with dozens of 30 byte template files.
Between my first reply and this one, you should have a very clear idea of what I want :) Say I wanted to modify an existing module rather than writing one from scratch. Where would you propose that I start?
Re: Re: Re: I am about to write my very own templating module..
by mirod (Canon) on Sep 26, 2001 at 15:06 UTC
|
I still don't understand the "this module is too powerful for what I want" argument. Isn't Perl itself too much power for most of the tasks we use it for?
That said you should really have a look at Text::Template. Granted its name does not include HTML, but it works really well for it anyway.
There was an interesting discussion about it on the TT mailing list, look for the "Pros and Cons vs Text::Template" thread. TT2 advocates had the same basic argument you have: they want a "crippled" templating language. Caching seems to me a better reason to choose TT2, but as they say YMMV...
| [reply] |
Re: Re: Re: I am about to write my very own templating module..
by echo (Pilgrim) on Sep 26, 2001 at 14:56 UTC
|
One of the main issues with homegrown templating systems compared to popular packages available on CPAN such as TT2 or HTML::Template is the performance: most writers of homegrown systems focus on the syntax, not on performance: parsing speed, compiling to Perl, caching, all these are hard to get right. A homegrown system with a simple parser written in Perl using regexes might do a fine job but will offer poor performance under heavy traffic. | [reply] |
Re: Re: Re: I am about to write my very own templating module..
by perrin (Chancellor) on Sep 27, 2001 at 02:46 UTC
|
HTML::Template and TT2 made it through my preevaluation. The final decision was taken mainly with respect to the fact that the script I'm writing is intended to work on a system with a barebone Perl5 and no way to install modules - as is the case with many cheap web hosts. HTML::Template only consists of a sinlge .pm - TT2 is no competition in this case.
Hmmm... if you can install one module, why can't you install 20? I would expect this to be an all or nothing situation. If you can drop one module in your local directory, you can drop all of TT there.
I embarked in working with HTML::Template. But the syntax is not well readable
I'm not a fan of that syntax either. I definitely prefer the aesthetics of the TT syntax.
There is no special case to deal with newlines around the <tmpl_*> tags, so you can't put them on a line of their own if you want the output to look neat and tidy.
TT handles that, as do some of the others.
The templating module I want would offer powerful interpolation syntax but not a bit more power in highlevel constructs than necessary.
But no one is twisting your arm and telling you to use the full syntax of TT! Just use the part you want. If you find out you need more of it later on, it will be there for you.
1) fetch data, build list
2) run filters over list to provide the template logic; variables get changed, added, deleted etc per record here
3) interpolate data into template
All non-trivial modules I have seen try to integrate step 2 and 3 inside the template.
Hmmm. I don't think I understand these steps. The pipeline model is all about doing all of your data munging before running the template. The template only has display logic in it, and doesn't modify any data.
Now, you could say TT2 allows me to do it my way even if it offers more power than I want. But besides being awkward to use when you cannot install modules, to me it feels like "the tail wagging with the dog" as they say in Germany. Total overkill. I do not need a module that comes in 20-odd files incl XS, compiles my template to interpolate it, and can make coffee and bake cake to boot.
The XS is optional, of course. TT is fairly big. However, size is only a problem when it does not fall within your required limits for disk space, RAM, speed, and ease of use. I don't use half of the capabilities that TT provides, but I love the fact that when a designer comes to me and says "I want to display these search results in two columns" I can say "Here's the TT table plugin" and not have to write it myself. I've had experiences like that over and over with TT.
Back when I was a Perl newbie, I did write my own templating system. I actually wrote a couple of them. (In my defense, TT didn't exist then.) 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 was seriously about to go with CGI::FastTemplate - small, simple, clean concept written in a no-installation-required single Perl-only module. Except I had written something very similar myself for a previous (unspeakbly ugly) script and have come to despise the templatelet mess it reinforces.
Glad to know I'm not the only one who feels that way.
Say I wanted to modify an existing module rather than writing one from scratch. Where would you propose that I start?
The closest to what you are suggesting is Text::Templar, but I don't know how easy it would be to extend. | [reply] |
|
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?
| [reply] |
|
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).
| [reply] |
|
Re: Re: Re: I am about to write my very own templating module..
by George_Sherston (Vicar) on Sep 26, 2001 at 17:59 UTC
|
the tag doesn't visually stand out against a page full of template HTML
I write my html in lowercase and my TMPL code in upper case. Stands out a mile, e.g.
<h3><TMPL_VAR HEADER></h3>
<h4>please log in:</h4>
<form action="input.pl" method="POST" name="mainform">
<input type=hidden name="Action" value="
<TMPL_VAR FUNCTION>">
user name: <input type=text width=30 name="UserName" value="<TMPL_
+VAR USER_NAME>"><BR>
pass word: <input type=password width=30 name="PassWord" value="<T
+MPL_VAR PASS_WORD>"><br>
<TMPL_IF LOG_IN>
<h4>if you don't have a user name, then you'll need to <a href="in
+put.pl?Action=StartRegister">register</a><br>and if you've forgotten
+your user name or pass word, <a href="mailto:<TMPL_VAR EMAIL>">email
+me</a></h4>
</TMPL_IF>
<TMPL_IF REGISTER>
security code: <input type=text width=30 name="SecCode" value="<TM
+PL_VAR SEC_CODE>"><BR>
if you don't know the security code, chances are you didn't get an
+ email from me inviting you to be here... if you'd like one, please <
+a href="mailto:
<TMPL_VAR EMAIL>">email me</a>
</TMPL_IF>
Having said that, I have some sympathy with your aesthetic reservations about >>! But seriously, I'd like to add my voice to those that say HTML::Template pretty much fits the spec you laid out. Certainly as I've found more and more imaginative ways of configuring the param() method, I've found there's no structure I want to use that it can't handle with ease. And the bonus is, it lets me do the complicated stuff in regular perl, not some strange module dialect.
§ George Sherston | [reply] [d/l] [select] |
|
|