Templated Separation of (Business) Concerns

| 1 Comment

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' %]


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.

1 Comment

Love TT. Thanks for posting about it.

That reminds me, I need to bug ABW about TT3. :)

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

sponsored by the How to Make a Smoothie guide



About this Entry

This page contains a single entry by chromatic published on August 18, 2011 5:12 PM.

10 Years Later, Only 250 SLOC was the previous entry in this blog.

No Policy Can Save Wrong Code is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Powered by the Perl programming language

what is programming?