I'd like to take this moment to thank my friends:

 - HTML::Prototype for making it damn easy to do cool shit like auto-completing forms.

 - Test::Class for giving me a really nice framework to run unit testing in.

 - Bricolage for giving me a good understanding of how to manage database fixtures inside a test case.

 - Catalyst for showing me how to do a web framework right.

 - Rose::DB::Object for an ORM package that works the way I do.

And the library I'd like to thank the most is: Template::Toolkit.
Template Toolkit provides an excellent template library with just enough richness to do cool shit.  It was the perfect choice to to replace scoop's block/box/var system with.  It has shown me just how wrong this comment is.

Simple scripting & conditionals do belong in the template system.  If you dont have them there, then you are putting display-code into places it doesn't belong.  The result?  You write giant functions that do mostly HTML generation (like to display the contents inside a list) that should be somewhere else.

I'm not just dissing on scoop's block/box system by the way.  I once worked on a system using a roll-your-own template system simialar to scoop's.  The result was Perl, SQL and HTML all mixed together into a huge ball of mud.  Adding new features took forever.  A simple shopping cart was 3000 lines of code.  Every feature was full of holes and impossible to test.

If you really looked at it, most of the code-bloat was doing a trivial pattern:

1. Display the HTML header.  But do it just a little different if you are condition B instead of A
2. Loop through all the objects I'm displaying, check a conditional or two, spit out HTML.
3. Now display some kind of footer for this object.
4. Repeat for every object in the document.

It takes a hell of a lot of logic to do something as simple as draw a cart!  In that system, the display logic was so intertangled into the code that all one could do was give up and copy&paste the logic used elseware in the system.  The codebase was rife with copy & paste jobs that would be virtually impossible to refactor.

Enter the template system with some control logic.    The example I gave is exactly the kind of problem template systems were designed to fix.  Rather then putting all the display logic in the code, you instead merely hand the template system an object, tell 'em which view to render, wash your hands, and walk away to do better things with your time.  They do all the heavy lifting of figuring how which cases to display and when.

In scoop's case, they could be used do all the "does this session have the permission to display X?".  In the other system, they could have handled all the various ways to display something "automatically".  300 lines of display code inside your modules turn into two or three.

"Ohhhh.... but they are all bloated.  TT, HTML::Template, et. al have done nothing but create a yet-another programming language," they say.  "Pretty soon we will have a perl interpreter ontop of perl interpreter and then what have we gained?"  This argument has some merit, some template languages appear to be nothing more than perl-on-perl. It is foolish, however, to use such an argument to dismiss the use of any kind of control logic inside a template.  A good template system provides just the right amount control and no more.

"Ohhh.... but they are slow and use a ton of memory! My homebrew super-wiz-bang template system uses assembler and uses only 6 bytes of memory."²  People who make this argument doing realize that something has to perform all the nasty crap required to spit out HTML.  Rather then into some simple templates, people with homebrew systems are forced to put it into their code instead.  While I can't prove it, I'd imagine the memory & cpu usage is way higher in such systems thanks to all the copy&pasting that starts to happen.  Dont forget the costs involved too.  Programmers cost WAY more then memory and CPU.  The nasty rats-nests concoted by those using ghetto-homebrew template systems take much, much more time to work on then those who have good, "stock" systems.  Basically, this arguement is nothing more then premature optimization at it's finest.

To sum it up, any time you roll your own template system, for whatever reason, god kills a kitten.  Just dont do it.

¹ aka, you the template programmer.
² http://scoop.kuro5hin.org/?op=comments&sid=2000/12/8/1364/10645&pid=3#4

Anyway... happy fathers day.  I gotta jet and I dont have time to fully proof-this.  Sorry.