Posts tagged ‘Jinja’
Testing Jinja Templates
2013-07-06 21:43If 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:
- {% macro hello_world() %}
- Hello world!
- {% endmacro %}
- import flask
- hello_world = flask.get_template_attribute('hello.html', 'hello_world')
- print hello_world()
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:
- class Hello(JinjaTestCase):
- __template_imports__ = {
- 'hello_world': 'hello.html',
- }
- def test_hello_world(self):
- result = self.hello_world()
- self.assert_in("hello", result.lower())
- self.assert_in("world", result.lower())
The JinjaTestCase base, implemented in this gist, provides evidence that a little __metaclass__ can go a long way :)
Self-Replacing Script Blocks for Dynamic Lists
2012-01-17 8:52On contemporary websites and web applications, it is extremely common task to display a list of items on page. In any reasonable framework and/or templating engine, this can be accomplished rather trivially. Here’s how it could look like in Jinja or Django templates:
- <ul>
- {% for item in items %}
- <li>{{ item }}</li>
- {% endfor %}
- </ul>
But it’s usually not too long before our list grows big and it becomes unfeasible to render it all on the server. Or maybe, albeit less likely, we want it to be updated in real-time, without having to reload the whole page. Either case requires to incorporate some JavaScript code, talking to the server and obtaining next portion of data whenever it’s needed.
Obviously, that data has to be rendered as well, and there is one option of doing it on the server side, serving actual HTML directly to JS. An arguably better solution is to respond with JSON or similar representation of our items. This is conceptually simpler, feels less messy and is potentially reusable as a part of website’s external API. There is just one drawback: it forces rendering to be done also in JavaScript.
Recent posts
