Re^2: The history of a templating engine

Just so there isn't any confusion, I'll hit a few of these points...

For code which should insert something into html I've used three different construct: @~...~@, ^~...~^ and #~...~#, so web designer is able to see: here will be inserted some text. Only difference between them is escaping: @~~@ add html-escaping, ^~~^ add uri-escaping and #~~#

See, this is what I would consider to be a bad design decision. This completely ties the templating system into HTML and with different syntax for different output. What happens if you want to use your template for something other than HTML and need a different type of escaping? What if you want to escape your HTML in different ways?

For example, internally on my site, I have a blogger style syntax processor. So I can type ~some text~ and it'll translate to some text automatically for me. I hate typing HTML all over the place. With your approach, to do something similar, you'd need to add in some sort of new embed syntax, or wrapper up a new function. With my approach, it uses pipes (ala unix) for the same effect - <% "~some text~" | blog %>. Sure, you define a new function, but you don't need new syntax to add new functionality.

Incidentally, I also made all of my template tags user configurable with no speed hit. So if you want to use something else, it's simply changing a value in a config file.

That's all, only 4 special tags!

Basset::Template has 7 special tags. 3 of are unquestionably syntactic sugar (the comment tags, the "big eval" tags, and the debug tags), leaving the return tags, eval tags, and include tags (and the cached include tags, but that's an optimization syntactic sugar). And I'm sure you don't have a problem with sugar, since the 3 different insert styles you have are arguably just sugar as well. :-)

I've used do{}, as Jenda proposed in previous comment.

This was an awesome suggestion (thanks Jenda!) and I have added it to the internal builds. Admittedly, it does prevent the user from typing in <% return $value %>, but I figured that it was a worthwhile modification to get rid of the anonymous subs.

150 lines of code (parser itself is 30 lines), less than 6KB.

Even if I rip out the documentation, examples, sugar, and unique features, i still only get down to 405 lines, so I'll give this one to you.

namespace issue I've solved by using no global variables (as mod_perl recommend), this way everything works fine in 'main::'

The globals are used for importing into the package that the template appears in. Otherwise, I didn't have a way to send variables into the template. I wouldn't mind hearing a non-global approach.
instead of using 'print' I've added text into some variable (accumulator), this solve STDOUT/OUT issue

As said in my original post, the filehandles are long gone, instead accumulating into a scalar. Though "print OUT" still exists for backwards compatability (not that I use it).
no problem with non-scalar variables and references because I can use any my() scalars/arrays/hashes

I have no problem importing non-scalars or refs, you just need to hand in a reference to what you want to the processing engine. I'm willing to bet you need to do that, too.
to comment my perl code I use usual #-comments inside <--& ... --> block, no need for special tag because that perl block will not be included in generated html anyway

Basset::Template could have comments as:
```
%% # this is a comment

or

<% # this is a comment %>

or

<# this is a comment #>
[download]
```
it's all pure sugar.

Comment on Re^2: The history of a templating engine Download Code

Replies are listed 'Best First'.
Re^3: The history of a templating engine by powerman (Friar) on Sep 12, 2006 at 21:59 UTC
See, this is what I would consider to be a bad design decision. This completely ties the templating system into HTML and with different syntax for different output. What happens if you want to use your template for something other than HTML and need a different type of escaping? What if you want to escape your HTML in different ways? Agreed. I've in TODO list this feature: - move parser from POWER::iCGI module into separate POWER::Template module and make it configurable a-la (shown interface is just an example of needed features, not proposed module interface): `use POWER::Template; my $t = POWER::Template->new(); # example configuration to simulate POWER::iCGI: $t->eval('<!--&', '-->'); $t->text('@~', '~@', \&Enc); $t->text('^~', '~^', \&EncUri); $t->text('#~', '~#', undef);` [download] This way parser become 100% configurable, will have same 30 lines of code or even less, and my templates will use "tags" and escaping/converting features suitable for each format - one in html template, other in email templates, etc. UPDATE: And don't forget, I don't write these comments to compare my template system to yours, I just wanna prove this task is much simpler than you affirm.	[reply] [d/l]
Re^4: The history of a templating engine by Anonymous Monk on Sep 20, 2006 at 07:18 UTC
I'm still waiting for the proof? I see some interesting design decisions, but I'm not seeing the "proof" that its simpler. I would appear that the writer thought a lot more about what someone could want to do someday, maybe. So, he's more generic and complicated. You are less generic and less complicated. That's about all you’ve proved to me.	[reply]
Re^5: The history of a templating engine by powerman (Friar) on Sep 20, 2006 at 10:43 UTC
Hmm. Can you ask less generic question, please? :) What exactly is 'less generic' in my solution? 'Tag names' and attached 'result convertion' action can be made configurable as I show in previous post without introducing significant complexity, if any. This way I'll have things like "<% ... \|blog %>": `$t->text('<%', '\|blog %>', \&MyBlog);` [download] 'include template' feature can be developed in many different ways, from simple including header/footer templates (which will in most case doesn't have any perl code at all, or will use few local()'ized global variables) to something OO-like which surely may be very complex.	[reply] [d/l]
Re^3: The history of a templating engine by ursus (Acolyte) on Jan 03, 2008 at 19:54 UTC
I'm looking at rolling my own template system as well. I had that "switch the quotes" moment as well, but without actually coming up with words for it. Anyhow, here's how I intend to handle the data thwomping problem, as well as `STDOUT`. Templates are to be mangled into: `use UrsusTemplate::tmpl; $tmpl_sub{$tmpl_path} = sub { my $out = ''; <i>some Perl</i> $out .= "<i>some HTML</i>"; return $out; }` [download] Which gets `eval`ed. As long as your code uses `my` (or the template engine inserts it), you have data safety. Imported via `UrsusTemplate::tmpl`, we have: `sub run { my $tmpl_path = shift; generate($tmpl_path) unless $tmpl_sub{$tmpl_path}; return $tmpl_sub{$tmpl_path}->(@_); #goto &$tmpl_sub{$tmpl_path}; #if you want to scare the other devs ;-) } sub emit { print $site_head; print run(@_); print $site_tail; }` [download] Now we have an easy way to do includes, plus an API for the controller. If we keep the timestamp from the source file, we can easily implement caching as well. If anyone can sanity-check this for me, I'd love that.	[reply] [d/l] [select]