More on Django

As I come to the end of my first project using Django, I can offer a slightly better picture of how Django actually measures up in the field. In general I found that the bulk of the application was easier than I'd expect, but the remainder was more time consuming than I'd expected.

As mentioned before, Django's weakest link is its rudimentary template language. Content and data has to be digested and spoon-fed to the templates because the templating language doesn't provide the tools required to manipulate data arbitrarily. This doesn't allow the separation of presentation and controller code that is the purpose of a templating language. Instead, each template has a one-to-one dependence on the code which sets up the model. On the plus side, it's very easy to track where the thread of execution goes in these templates. A potentially dangerous issue is that the templating system defaults to not escaping data variables. This is effectively XSS unaware. Inverting the semantics such as to escape everything unless I tell you otherwise (to insert XML/SGML markup, say) would fix this.

The philosophy given by the Django documentation for the design of its templating is that

We wanted Django’s template language to be usable for more than just XML/HTML templates. At World Online, we use it for e-mails, JavaScript and CSV. You can use the template language for any text-based format.

This "one size fits all" approach is self-evidently misguided. XML and JSON need a guarantee of structural validity but they rarely need re-styling anyway. (X)HTML needs escaping. Javascript (other than JSON) should be static anyway. CSV barely needs an API, let along a templating language. Emails... well, OK, this is a fine templating language for text-only emails.

I'd also found my Django application hard to structure. Views (functions called by the Django context in response to different request URIs) shouldn't contain application code. Following that philosophy, my code is split mainly into four classes in two Django "applications", a handful of utility functions in the ORM models, and everything else is wrapped up in the 20 or so views. They don't do more than delegation and template context setup, but there be semantics in them there views, and those semantics aren't codified a form that can be nested and built into more advanced and interdependent web applications. For larger applications, Django will need code to modify and extend the framework, but there isn't a good API to plug in this code. It's a mixture of adding the class names to the config file, and giving modules special names within the package.

These issues tends to convey to me the general sense that Django code is hard to tie together. Overall, to build an application as elegantly structured as my current web shop code would require a sizable layer on top of the Django framework, with the occasional aspect of Django re-written too. But then, my current shop code has already borrowed some of the best aspects of programming with Django as well as a handful of other frameworks too ;)