|
|
Re: What Do You Look For in a Template Engine?
|
Posted: Jul 23, 2007 11:22 PM
|
|
About a year ago, I wrote an entry in the FreeMarker group blog about the designer-developer division of labor:
http://freemarker.blogspot.com/2006/07/designerdeveloper-division-of-labor.html
Basically, I argue there that the whole templating discussion needs a sort of paradigm shift; in the general case, you need to think in terms of 3 basic roles in web development. Once you do that, a lot of the fallacies and muddled thinking kind of get washed away.
I would add here that one basic problem in this whole discussion is the way terms are used in a very unrigorous way -- simple, complex...
Now, simplicity/complexity has one paradoxical aspect in this discussion: using a more powerful templating language, i.e. with more features, that is, in a sense, more complex, may well lead to simpler templates, because the extra language features help you manage the complexity. Similarly, large programs in legacy languages like FORTRAN or COBOL tend to become unwieldy, i.e. complex, not because the languages are themselves complex, but rather, because they are overly simplistic, lacking in key features that are needed to build large systems.
Key fallacy 1: The desire for "simple" templates is not the same thing as the desire for a "simple" templating language. I am pretty sure that there is a range in which having a simpler (less powerful templating language) will lead to more complex templates to solve the same presentation tasks. (Or, alternatively, the complexity gets pushed back into the java code, which is a clearly violation of separation of concerns.)
Terence Parr seems to be quite guilty of the above fallacy in his article on model-view separation. A related fallacy is the notion that having programmatically complex templates necessarily means that you have model-view entanglement. The fact is that simply presenting data sensibly across a wide range of input and usage scenarios is potentially quite complex.
Key Fallacy 2: That your templates are complex does not mean you're necessarily doing anything wrong. The complexity is there, and is in the nature of the problem space. The issue is in managing the complexity. Pushing the complexity into your java code is obviously not the solution, since that clearly does violate separation of concerns.
Terence also sets up certain straw-man positions that are also reflected in this blog entry. He seems to imply that normal use of a popular template engine such as freemarker involves the template actually mutating domain objects. This is really about 180 degrees away from the truth. Now, the potential for this exists insofar as the application can expose java methods to the view. And those java methods can, in principle, do anything. But similarly, you can argue that the potential exists for a template engine such as freemarker to reformat your hard disk -- assuming that somebody exposed a method to your template that does that. But that's silly, right?
The fact is, the normal usage pattern espoused is that the data model exposed to a freemarker template is immutable. For example, when you write [#assign x = "y"] in a FreeMarker template, you are not altering the data model. If there is a variable named x in the data model, you are simply hiding it (due to scope resolution rules) by defining a variable x in your template, you are not altering the x in the data model. In fact, you can still get at the x variable defined in your data model via ${.data_model.x}. FreeMarker has no built-in syntax for assigning variables within the data model For example, something like [#assign foo.bar = "blah"] is not even valid FreeMarker syntax. To allow the template writer to mutate the data model, you really need to go out of your way to expose special methods that do it. By design, FreeMarker makes this difficult, but not impossible.
But again, normal usage of FreeMarker does not involve the template code mutating domain objects, and certainly does not involve making direct SQL queries to a database. That you can expose methods that do those things (and surely some people do) is another matter, but it is not normal encouraged usage.
So, the suggestion that a popular template engine such as FreeMarker encourages model-view entanglement is based on extremely stretched argumentation that is clearly of a straw-man nature. FreeMarker is in fact carefully designed so as to <i>discourage</i> model-view entanglement. Though, I do grant that it does not render it impossible.
In any case, Frank, you state that Velocity "provides a very capable template language". (Of course, it depends on your definition of "capable", but compared to what?) Anyway, you say it provides this capable template language, but your templates became unwieldy. Is this not a contradiction?
For starters, is it not a fallacy to think that if your templates became unwieldy with template language X that you need a template language Y that is more simplistic? If a large FORTRAN or COBOL program becomes unwieldy, does this imply a need for a more simplistic programming language or a more powerful one?
My own interpretation (and I could be wrong, of course) is that your Velocity templates became gradually unmanageable because Velocity is an extremely underpowered tool that lacks key things you need in a template language.
In any case, I am quite interested in reactions to my above-cited blog entry at http://freemarker.blogspot.com/2006/07/designerdeveloper-division-of-labor.html
My honest feeling is that there are a lot of fallacies floating around about the whole template topic and it would be useful to have a serious discussion about it to clear the air.
|
|
Previous Topic
