or staring at grains of salt.

I am currently very very frustrated as I am trying to create a brine for making a nice smoked shoulder for a party Saturday and for the life of me, I have been unable to find pickling salt! Pickling salt is very very fine and does not contain the anti-clump agents (usually corn starch and potassium nitrate), and iodine (that which makes the ocean smell like the ocean). It also dissolves in cold water. Regular table salt gives pickles or brined meats a brown-orange color, can add a somewhat ‘fishy’ smell to them, and does not readily dissolve in cold water. Defiantly not what I want for smoked pork. I am heading to a local ethnic butcher in the morning to pick up my meat order, and I am hoping they have some. All this reminded me I wanted to make a post about the recent discussions around the default template system in Django.

There are a number of posts about logic in Django templates. The short version for those who do not want to do a bunch of reading:

  • Django template logic contains a minimal set of functional operators, but no real logic operations (i.e. you can’t write {% if len(items) < 3 %})
  • Why not just use python as the template language?
  • You can use other template engines in Django, the doc is very poor on this, or how such integrations would work.
  • Django tries to strike a balance and meet the 80/20 rule for template use cases or ‘hit the big bulgy part’ of the bell curve of users.
  • Complex logic in templates is bad. The language should be minimal, and designed for UI writers.
  • Complex logic in templates is good. UI writers are not stupid, give them power!
  • Design is now in CSS, and HTML is the structure, thus an integral part of the programming producing that structure, not design.

Ok, that is the extreme cliff notes version, and I apologize if I am misrepresenting anyone here. There are many good points being made and some differences of opinion. I have my own opinions here, but first lets see what a very experienced PHP expert has to say on the matter circa early 2006:

Hopefully you found some simple ways to improve your template design, but also recognised that some complexities can arise when doing this and sometimes comprimises must be made.
One (simplified) way to look at it is like this:

You should be able to completely change templates, including all image files and CSS files, without having to touch any of your PHP files.

All fundamental data required in your templates should be fetched or determined ahead of time and assigned to your templates (this doesn’t include meta data, such as the length of a string, etc.).

That bolding is the authors emphasis, not mine. I believe the Django template system helps make this type of separation between templates and logic. I agree with Jacob that it strikes the right balance and hits that sweet spot. There was another blog post which summed up my feelings quite nicely, but of course, I cannot find it for the life of me. For PyCon-Tech I added a lot of logic to the templates. I felt I could make up the difference in the CSS. For some of the CSS, I templetized that as well! I made custom template tags for modifying the local context (variable evaluation and assignment no less), and went so far as to have a filter which modified and saved the model! The Idea there was if you included or extended the template, you were viewing that data, and you wanted to update the ‘last_viewed’ record.

PyCon UK is using PyCon-Tech, for the proposal system at least. But the templates are so complex, and the logic for the structure is very difficult to integrate into another site which is not based around having the navigation style of us.pycon.org. The end result is the coolest applications will not be used. The templates are code, and thus the structure is part of the code. The end result is, the templates are not templates, they are code. It might as well be python, and thus to use the conference framework for your conference of choice, you must change the code. This is with old Django functionality even. YUCK! My main mistake here is that I have much of the page structure determined by user permissions which are determined in the template. Once you make that decision, it kind of cascades to everything else.

Now some people have no problem with this, and are smart enough to keep their html structure generation code clean enough that CSS is all you need to change (Plone comes to mind here). For those people, I guess there is nothing wrong with python as the template language. Coincidentally I was talking with a friend about implementing PHP in python recently. We came to the conclusion that this would not be too hard to do. It would require a bit of encoding magic, a custom import loader, a module level meta class, some minor monkey patching to __builtins__. Now there is no need to do all this if what you want is python as the template language. For that, a custom encoding, and a module level metaclass should be enough:

# -*- encoding: python-template -*-
<%python
import pytpl
__metaclass__ = pytpl.metaclass
python%>
<head>
<title>foo</title>
</head>
<body>
<%python
for i in xrange(30):
    echo(i) # importing pytpl, and the metaclass adds echo to the module global namespace,
          # maybe it does a magic_escape? wait, thats another post…
python%>
</body>

This is basicly a pybraces on steroids, and adding an ‘echo’ and maybe some other minor additional helper functions. The encoder code builds a template document model for the local contexts and replaces them with ‘echo’ calls for that text. All echo does is add the text to a document or string queue. the metaclass deals with things like adding a __main__ block which if run from the command line will print the string queue to stdout. If a imported as a module, well there are other features added to the module like functions for adding variables (context) to the template, dealing with other template imports, getting the rendered string, etc. I have no real desire to work on such a project, but some times an idea grabs a hold of you. Why not use python as the template language? Well I have my opinions on why I would never use such a system, but that is my choice.