If you use a powerful HTML templating engine – like Jinja – inevitably you will notice a slow creep of more and more complicated logic entering your templates. Contrary to what many may tell you, it’s not inherently bad. Views can be complex, and keeping that complexity contained within templates is often better than letting it sip into controller code.
But logic, if not trivial, requires testing. Exempting it by saying “That’s just a template!” doesn’t really cut it. It’s pretty crappy excuse, at least in Flask/Jinja, where you can easily import your template macros into Python code:
When writing a fully featured test suite, though, you would probably want some more leverage Importing those macros by hand in every test can get stale rather quickly and leave behind a lot of boilerplate code.
Fortunately, this is Python. We have world class tools to combat repetition and verbosity, second only to Lisp macros. There is no reason we couldn’t write tests for our Jinja templates in clean and concise manner:
JinjaTestCase base, implemented in this gist, provides evidence that a little
__metaclass__ can go a long way :)
Flask is one of the countless web frameworks available for Python. It’s probably my favorite, because it’s rather minimal, simple and easy to use. All the expected features are there, too, although they might not be as powerful as in some more advanced tools.
As an example, here’s how you define some simple request handler, bound to a parametrized URL pattern:
This handler responds to requests that go to /post/42 and similar paths. The syntax for those URL patterns is not very advanced: parameters can only be captured as path segments rather than arbitrary groups within a regular expression. (You can still use query string arguments, of course).
On the flip side, reversing the URL – building it from handler name and parameters – is always possible. There is a
url_for function which does just that. It can be used both from Python code and, perhaps more usefully, from HTML (Jinja) templates:
Parameters can have types, too. We’ve seen, for example, that
post_id was defined as
int in the URL pattern for
blogpost handler. These types are checked during the actual routing of HTTP requests, but also by the
Most of the time, this little bit of “static typing” is a nice feature. However, there are some cases where this behavior of
url_for is a bit too strict. Anytime we don’t intend to invoke the resulting URL directly, we might want a little more flexibility.
url_for to format the
blogpost URL pattern:
Assuming you don’t feel dizzy from seeing two templating languages at once, you will obviously notice that
'< %= post.id %>' is not a valid
int value. But it’s a correct value for
post_id parameter, because the resulting URL (
/post/< %= post.id %>) would not be used immediately. Instead, it would be just sent to the browser, where some JS code would pick it up and replace the Underscore placeholder with an actual ID.
Unfortunately, bypassing the default strictness of
url_for is not exactly easy.