note jimt 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! [cpan://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. <ul> <li>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. </li> <li>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).</li> <li>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.</li> <li>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: <code> %% # this is a comment or <% # this is a comment %> or <# this is a comment #> </code> it's all pure sugar. </li> 572402 572618