So I've been reading Terence Parr's excellent addition to the Pragmatic Programmers catalog: The Definitive ANTLR Reference. This book is a lot of fun for me (I recommend it highly, btw), because it's gotten me thinking again about languages and language implementation issues in a way that I haven't had to since my first compilers class. Dr. Parr has a relaxed and informative writing style that can make you forget you're reading about some pretty hardcore computer science.
I wanted to do some more reading on StringTemplate, the templating engine ANTLR uses to emit the results of its translation, because I read that it can be (is) used to build websites as well. My searching led me to Dr. Parr's paper from 2004: Enforcing Strict Model-View Separation in Template Engines. In it, Parr explains -- and most importantly formalizes -- his ideas about the need for strict separation in view templating mechanisms, and how the vast majority of existing solutions (e.g., JSP, Velocity) fall far short, ironically because of the Turing-complete power they provide.
We Java programmers who have been around since the introduction of JSP have already been informally exposed to some of these concepts, in the form of the Model 1 -> Model 2 architecture evolution. One of Dr. Parr's key points, though, is that it's not enough simply to recommend avoiding using the full computational power available in (for example) JSP scriptlets. The temptation to use that power, even in seemingly innocuous ways, is simply too strong to be resisted for long. Parr's insight that having full access to the Turing-complete power inherent in JSP/Velocity/what-have-you actually gets in our way as developers reminds me of the 37Signals take on embracing constraint.
Mind you, I don't expect to be organizing a revolution around replacing my company's use of JSP with StringTemplate anytime soon. But I do plan to develop the personal discipline of following Dr. Parr's advice and embracing constraint by voluntarily avoiding the constructs that violate strict separation. That statement may seem to contradict the statement above about temptation being too strong, but I think that if enough individuals had the same resolve, we could improve the situation somewhat until a move to StringTemplate or its equivalent became politically feasible.
3 comments:
I always found it very useful to only have GUI logic in my JSPs / templates. So only FOR and IF JSTL tags and when using IF only test for GUI logic:
IF (showMenu) { ... }
not
IF (user.loggedIn && user.bookedProducts) { ... }
The first one has GUI logic (which should be set somewhere else), the second one has business logic and should be avoided. The same goes for variables. Never set variables in templates and never modify state.
Peace
-stephan
--
Stephan Schmidt :: stephan@reposita.org
Reposita Open Source - Monitor your software development
http://www.reposita.org
Blog at http://stephan.reposita.org - No signal. No noise.
Sounds reasonable, Stephan. Unfortunately, once the genie of Turing completeness is out of the bottle, chances are we programmers are going to use it. I know it seems unnatural to consider limiting the power of templates, since we're so used to being able to write full-on Java code in our JSPs. Kudos to you for recognizing the advantages of this approach.
Thanks for your input!
Yes, that isn't easy. I've been using code reviews and static architecture checkers to ensure these rules in the past.
Using a restrictive templating engine like ST is an option too, often you're bound by legacy code or developer skills though. I've been toying with a Javascript ST implementation and find the idea of ST very pleasing. As is the idea behind RIFE.
Peace
-stephan
Post a Comment