Passive templates and extreme programming

What are the properties, that make particular tool a better match for XP than others? To me these are:

• simplicity
• testability
• support for refactoring

Simplicity

Let's start with simplicity. Passive templates are processed by simpler engines, because they don't need huge languages. Many don't even need a particular syntax as they transform the xml parsed by a vanilla xml parser. This reduces the amount of knowledge to handle the tool. The templates get simpler, too, as the logic is removed. It can't be expressed by passive templates. On the other hand the logic, freed from template code gets very condensed which makes it much easier to handle.

Though, in fact tool is simpler, template is simpler, logic is simpler. Really?? No, not always. Of course the tool is always simpler. But the separation of template and logic needs some complexity to pay. As long as there is not too much logic to handle it might be considered more convenient to mix it into template code. This is a fact that has to be weighted against tool simplicity, learning effort and so on.

Testability

Automated testing is one of the most important tools used in extreme programming. And especially testing the user interface is a big problem domain. Martin Fowler has made his considerations on passive views. In fact the separation of logic and template allows much simpler testing of the logic. In many cases it even provides a convenient testing of the template. Of course the automation of template testing remains complicated. But back to the logic. Once you have pure java logic, free from template code it get much simpler to test. The API of such a simple template engine is typically easy to mock, which makes it really fun to get the test double in place.

Especially Snippetory is well-prepared for such activities. Template is an interface and materialized by TemplateContext. TemplateContext is well-prepared for injection and overwriting a single method provides one with the possibility to place mocks or interceptors as needed. This allows to analyze the calls together with the results of these calls as they appear in the generated code.

Refactoring

The next point is refactoring. How is this eased by passive template engines? There are different directions. The most obvious one is tool support. If you have your logic in java, you can use all the java refactoring tools of your IDE. On the template side those win might be somewhat smaller, but the easier template with not that many dependencies needs not as much support. Though, it at least feels much better.

Another direction are the possibilities, what can be achieved by refactorings. This starts with reusing the same logic with different templates, or vice versa the same template with different logic. This allows a number of patterns impossible with the traditional mixed approach like metaphor repository.

Another direction is the fact, that a passive template does not reference java methods. This helps very much if you want to rename or remove one of those methods you don't have to change the template. The traditional approach implied a number of problems. First the refactoring methods of some IDEs don't rename these methods in templates even if they would be accessible. The next problem is, the template is not compiled, and so we are not notified about this the error. While every engine based on passive templates has some kind of string based interface, too, this is exclusively used between the template and controller. Changes on the model will not break this interface.