Templated Separation of (Business) Concerns

Any decent web (or GUI application designer) will tell you that the separation of concerns recommended by patterns such as Model-View-Controller is critical to the maintainability of any project with business logic and some sort of UI.

This, of course, leads to all sorts of mistakes by people who follow the letter of the pattern and not the spirit of the pattern. (The spirit of the pattern is "put things where they belong, like with like, and mix the two only along well-defined encapsulation boundaries".) That's why abominations such as XSLT exist: by creating a Turing-complete programming language in which no sane programmer would voluntarily perform anything more complex than simple substitution more than once, you've ensured that a template will never contain anything as complex as iteration. ("Iteration? Isn't that business logic? Shove it on in the model then!")

Me, I've used a different slightly different take on this pattern on a few recent projects, and I've found it exceedingly useful.

Consider the TT2 code:

[% META title = 'some page' %]
[%- USE Math -%]
<div id="fullcontent">
<h1>Some Page</h1>

[% INCLUDE 'components/copy/some_page_text.tt' %]

...
</div>

Where I'd previously have included components where they perform parametric template abstractions (that is to say, where I'd use a function in code), I've started to use components for the text portions of pages.

I first noticed this as a useful technique when I had to add a legal disclaimer and click-through in a user registration system. My customer told me it'd probably change in the next several months. Rather than explain how Template Toolkit works, I decided to explain "Edit this single file as HTML to change the license" and be done with it.

Since then, I've used it on a couple of other projects where the presentation of data and the explanation of data may change separately. Rather than searching through an entire tree of templates for a wording change, I can search through a subtree of copy. (I suspect this technique may also lend itself to localization, but I have no direct experience of that.)

If I were to hew to a strict reading of MVC or another pattern governing the separation of concerns, I might have stuck with the fallacious idea that all view code is view code and all model code is model code, and any and all mingling in a layer is okay. (I exaggerate for effect.)

Fortunately, using a good foundation or libary or toolkit allows the separation of concerns within a layer.