PitStop

I’m a big fan of Jon Bentley, the author of Programming Pearls. In this book, he discusses elegant solutions to problems that have irritated programmers for years. (I was in Europe for 6 weeks last year, and this was the one book that remained consistently in my bag throughout the whole trip. I’m not joking.)

In chapter 3 of the second edition, Bentley demonstrates how “form letters” (another name for templates) can be used to solve some particularly tedious programming problems.

Like most web frameworks, Django (everyone’s favorite web stack) ships with its own template engine. In pretty much any Django tutorial, you’ll find a section on how to use templates to implement the dynamic pages on your website. This can lead to a sort of tunnel-vision that causes you to forget that templates exist outside of the world of dynamically generated HTML.

However, as Bentley was so kind to remind me, templates are good for so much more than generating HTML pages to be served over HTTP. I often find myself attacking ugly problems with a silly custom solution until I have that aha! moment in which I realize that templates are the perfect answer.

A couple of examples:

Email templates:

I do contract web development here and there. About a year ago, I was working on a client site that sent automated plain-text emails to users in response to certain events. The site owner wanted an easy way to edit these emails. I won’t tell you how silly my first solution to this problem was.

Luckily, I was quick to realize that plain text can be templated just as easily as HTML can. So, I made a template directory specifically for these emails, and documented the variables that would be passed into each template in comments at the top of each relevant file. The code to send the emails involves querying the relevant information from the database, producing a dictionary of key-value pairs from this data, and feeding this into the appropriate template to produce the email text.

The best part was that when the site owner decided that he also wanted to maintain HTML versions of his newsletters, I was able to use template inheritance to keep all of the text for both plaintext and HTML versions of each newsletter in one place.

XML API responses:

My masters thesis was in data management. If you had walked by my desk on any given day when I was working on my thesis project, you probably would have heard me muttering “I hate XML” as I stared maniacally into my editor window.

The StopFinder XML API was one of the last features to be implemented before our 1.0 release. I was starting to get a wee bit tired. Coffee was becoming more of a dependency than a performance enhancer. You know how it is. The last thing I wanted to do was mess around with code to build XML responses. Parsing it is bad enough.

After about five minutes of reading about different Python modules that can build XML documents programmatically, I had the predictable aha! moment. Why not just use a template to specify how the response should look? My favorite thing about using templates to implement XML responses is that the document structure is very obvious to maintenance programmers, in comparison to some nasty module that uses the DOM to build a document in code.

One word of warning with this approach: The natural way to implement an XML API from here is to write a vanilla view function to accept POST requests, or something like this. However, if this view function is in the same app as the rest of your site’s functionality, an out-of-control API consumer could potentially bog down the performance of your entire site. A better thing to do would probably be to run a seperate Django instance specifically for your API. Of course, if the API hits a shared database really hard, you’re probably going to be in trouble no matter what. But that’s a story for another article.

So, the lesson of the day is to remember that templates are a general purpose tool. This is probably obvious to most clever folks, but the slow ones like me occasionally need to be reminded.