I noticed the following in the introduction for StringTemplate:
StringTemplate interprets o.p by
looking for property p within object
o. The lookup rules differ slightly
between language ports, but in general
they follow the old JavaBeans naming
convention. StringTemplate looks for
methods getP(), isP(), hasP() first.
If it fails to find one of those
methods, it looks for a field called
p.
This doesn’t seem to jive with this paper: http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf
Doesn’t this open the door for violations of model/view separation, by essentially allowing the model to pull data by calling a method? A bad programmer could write a method getP() that causes side effects. How does ST “strictly” enforce the separation of concerns here?
Every single templating language out there does exactly that, Velocity, FreeMarker, StringTemplate and JSP/JSF Expression Language.
The separation of concerns is something the programmer should care about, not the view. People are expected to write side-effect free get/is/has methods so that anyone can call them without having to care about this. That’s why these methods are supposed to be accessors and there are methods usually called with setSomething that are supposed to be mutators.
If someone writes their own classes and decides to define a getSomething method that has a side effect, they are going against the common belief and the tools are not supposed to take every single assumption when dealing with objects, they just hope people will be intelligent and will respect the common sense and write code as everyone else writes.