http://blog.brandonbloom.name/2009/08/url-routing-and-views.html

So far at work, despite having a dedicated designer, the programmers have been building all the templates and here’s why:

A template author has to understand the dot notation for traversing the object tree, this means they need to KNOW the object tree and how it works in relation to the dot notation. Say I have a variable ‘n’, and I want to access the nth object in an array ‘foo’ in the template, a designer might incorrectly try to access foo.n, instead they’d have to ask the programmers to write a filter so they can write foo|arrayget:n or something similar. When in jinja2 you can just write foo[n].

Whenever a template designer needs to access a method on an object that would normally take parameters, they have to either ask the coder to refactor the context and models or to write a custom tag (which is a very untidy process). This seems to be doing the opposite of seperating design from presentation – I’ve found myself adding numerous methods to my models and hacking getattr simply for the purpose of making some small template use cases possible.

Just because something is in a template, it doesn’t mean it doesn’t need advanced logic. A template designer using Django is going to have to get their toes wet with Python as soon as they start doing anything beyond a very simple blog app.

Now here’s the kicker: The Django template language is no easier to learn than Python (because Python is famous for its readability and ease of use/learning), but it does introduce a horrendous stack trace for debugging, an unneccessay burden on the programmers to modify context, and write filters or tags. Not to forget the godawful syntax for conditionals, just to get around writing an equality in Python.

The reason jinja2 is nice is that it’s superficially a superset of Django’s own template language, a template designer can use the designer-friendly syntax as far as possible – but dip into the ‘advanced’ syntax for those rare occasions when they need something more.

It’s some tricky business.

http://code.djangoproject.com/browser/django/tags/releases/1.1/django/contrib/admin/views/decorators.py#L58

Several others have shown interest in our approach URL routing to authorization. It seems I wasn’t clear enough about how or why our system works. Your solutions don’t fit our needs exactly. What I came up with isn’t much more complex than what you’ve got. I’ll try to write a follow-up post within the next week or two.

In short, my stance on the template language debate is: we don’t have dedicated designers and we don’t expect to have any soon. Django wasn’t made for programmers, so we’re using something that was.

As for username authentication, the problem is that the default User model and schema enforce a unique, not-null constraint. All users must have a username. It is far from an insurmountable problem: I overrode the save function, called super.save, set username = id, then called save again.

I didn’t always just throw out Django, I made it work for me. In some cases, it was faster, easier, and produced better results to just rewrite things. I was always picking the path of least resistance.

Cheers,

-Brandon