Re^3: The history of a templating engine

[powerman]

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);

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.

[Anonymous Monk]

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.

[powerman]

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);

'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.