Using StringTemplate as a ViewEngine for ASP.Net MVC
I've been in love with the simplicity of MVC frameworks from day one. But I've always felt like the accompanying ViewEngine needed an equal measure of simplicity to have the greatest value. Having worked with ASP.Net MVC since preview 3, I realized pretty early on that if I didn't find a ViewEngine I could get on board with, I'd find myself running back in defeat to ... WebForms (gasp).
The good news: ASP.Net MVC offers 4 ViewEngines out of the box (assuming you include the MVC contrib project).
The bad news: I don't really like using any of them.
The best news: I'm not stuck using any of them.
After kicking the tires on every ViewEngine I could get my hands on (including hacking my own template language just for fun), I became frustrated with endless pages of "tag soup". My search for something lightweight, fast, easy to read, and wrist friendly led me to a solid product called StringTemplate. For those who've never heard of it, you can check it here. It's in Version 3, and has an active user community. Here's a scrape of their front page:
StringTemplate is a java template engine (with ports for C# and Python) for generating source code, web pages, emails, or any other formatted text output. StringTemplate is particularly good at multi-targeted code generators, multiple site skins, and internationalization/localization...
...Its distinguishing characteristic is that it strictly enforces model-view separation unlike other engines. Strict separation makes websites and code generators more flexible and maintainable; it also provides an excellent defense against malicious template authors.
True Model-View separation
So what does StringTemplate mean by "enforces model-view separation unlike other engines"? Well, for starters... string templates are not compiled C# classes like ASPX pages. They utilize a highly simple attribute container (similar to ViewData in a controller). There is no variable instantiation in templates. All data processing must take place *before* you get into the template. The only logic that is allowed inside the templates are simple conditional statements and foreach loops.
Now, before you hit the back button on this article, you might want to really consider what you use ASPX pages for anyway. When it comes down to it, if you remove the data calls from a server control, all that's left are attributes, looping, and conditional statements. In other words, logic that is UI specific.
So, when it comes down to it, they only thing you actually lose when giving up access to C# code in your template ... is the ability to hack business logic into your UI layer. This would be a good thing. StringTemplate removes the temptation, because it removes the ability.