However, in many jobs shops, the HTML-whacking is done by people who specialize in that, and are generally better at driving DreamWeaver and Photoshop than they are at driving Emacs (or even vi).

Many people have reported that they can comfortably teach-by-example to these designers the mini-language of TT far faster than trying to explain why it's @foo in one place, but $foo[3] somewhere else.

So, while a mini-language may not make sense for you, it makes a great deal of sense in these shops.

Also, I find that having a mini-language keeps me honest about MVC. About the time it starts getting hard to write in TT, I realize that I'm actually writing control or model code, and that code belongs away from the view code. So, I rip that out and put it in Perl or SQL where it belongs.

So, while a mini-language may not make sense for you, it makes a great deal of sense in these shops.

Ack, thanks for pointing that out. There are also those shops in which they don't want to know or do anything beyond the design and layout, and consider inserting loops or conditionals or even variable templates as being "not their job".

Also, I find that having a mini-language keeps me honest about MVC. About the time it starts getting hard to write in TT, I realize that I'm actually writing control or model code, and that code belongs away from the view code. So, I rip that out and put it in Perl or SQL where it belongs.

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

I love perl particularly for what is said in the perlmodlib manpage note at the end: "It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun."

greets,
--shmem

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.