Then you are using the restrictions of the mini-language to discipline yourself? It's a good thing to put up fences which thou shalt not pass, but it's better to have them "inside".It's not so much a restriction as merely a place where it starts getting interestingly harder.
I don't consider the edge-of-road markers that make a very loud noise in my car when I start to drift a "restriction" either. After all, I can ignore the noise, and keep driving off to the emergency shoulder, as I might need to do occasionally. However, it's a nice warning that I need to rethink what I'm doing.
TT's limits are more like Perl's "warnings": they can be ignored if you choose, but they seem to kick in almost always at the right time. After all, the thing I wrote to handle my photograph library is a huge 400-line TT component, and it does an insanely large amount of data wrangling that really belonged in a controller somewhere. But I still use that in production (until I replace it with something more ajax-like soon).
And that's what I like about TT. I can putter around in it, and do model and controller things there, but I'm well aware that it should really be moved somewhere else. With Mason applications, I often see a ton of code in a URL that really belongs in a testable class as a controller or model code, because with Mason, the cost is actually less to put it at a URL instead of in the proper place. This is the danger of Mason (similar to the danger of PHP).
-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.
In reply to Re^2: Why a mini-language? (was Re^3: RFC: Templating without a System)
by merlyn
in thread RFC: Templating without a System
by shmem
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |