ivixlog

A month of Django

April 10th, 2008 | by dan |

The best way of learning is by doing, so a month ago I set myself the task of learning Django by using it to create a simple web app. About three weeks ago, I briefly wrote up my first impressions of Django. For the benefit of the untold masses which are no doubt hanging on my every word, here is the first-month report.

This is from the point of view of someone who’s been writing CherryPy based webapps for the past couple of years.

URL Dispatch

Now, I’m used to CherryPy, in which the URL structure of your site is dictated by the class structure of your views. This is quite cool, or at least it was in 2005 when I started using it. Django does things in a more conventional way, by having a mapping of url regexes to code functions.

First impression was that this would be a hassle - just another thing to have to think about. In practice however, it’s a useful abstraction, especially when dealing with library code. You just import some views from a package and slot them in anywhere within your site. Great for code re-use, and for internal refactoring.

Middleware

Middleware in Django is analogous to filters in CherryPy, and provide functionality like sessions, authentication, and whatever else you’d like to happen at various stages in the request/response cycle. Unlike the muddled and always-changing filters of CherryPy, Django middleware is simply defined by an ordered list of module references. In my experience, they Just Worked.

Debugging/Logging

When developing with any framework or any codebase you didn’t write yourself, it’s essential to be able to get at the guts of the system to see what’s going on. Nothing is more frustrating than having to debug via brute-force methods. Thankfully the logging and error reporting of Django is on the whole, quite good. I don’t see the point of the ‘pretty’ error messages - I always click ‘copy-paste view’ to see what’s going on. Having said that, some newbie errors I made resulted in some rather obscure exceptions being raised. Would have been nicer if some basic sanity checking was done and some more descriptive exceptions raised instead.

Sessions, users and registration

While sessions and basic user authentication is built into Django, if you want users to be able to sign up or to use more exotic authentication mechanisms such as OpenID, you’ll have to go and get those modules from somewhere else. For some reason they all seem to be on Google Code - maybe because Google loves Django. Luckily, due to Django’s modular nature, they integrate without too much fuss. The libraries themselves have a way to go to become mature, but they are fully usable as of now. I am sure they will improve rapidly.

Templating

Despite what I said a month ago, the Django template system is kind of growing on me. Template inheritance is straight-forward and there’s no XPath stuff all over the place. The {{ }} syntax is a little unnatural at first, but bearable. Debugging is good, telling you where the error is, unlike Kid templates.

Database ORM

No suprises here. This does everything you’d expect an ORM these days to do. Nice and easy learning curve. You’ll pick up the basics in no time.

Flexibility

All I can comment about this is that my app required me to import into the database via an external script, and it didn’t present any major boggles;

sys.path.append('/path/to/project/')
os.environ['DJANGO_SETTINGS_MODULE'] ='project.settings'
from django.core.management import setup_environ
from project import settings
setup_environ(settings)

And you’re ready to go.

Conclusion

For very ‘custom’ web applications, what you want is something which handles HTTP and then gets out of the way, which CherryPy does quite well.

For a public-facing ’standard’ web application, Django is awesome, and I wouldn’t start a new project using anything else. It will certainly become the de-facto Python web framework. A clear leader in this area is something that will greatly benefit Python, in a similar way to how Ubuntu is becoming the de-facto distribution (No, Gentoo doesn’t count). The community can now hopefully start to unite behind Django and Python can really assert itself as the natural replacement for (the abomination known as) PHP as the free web language of choice.