Well, this morning I learned about Rails and now I’m moving over to the Python world with and introduction to Django. Maybe I’ll look at the Perl take on MVC web frameworks tomorrow by attending the Catalyst tutorial; I haven’t decided yet. This tutorial is being given by Jacob Kaplan-Moss, and he’s put his presentation materials online.
I don’t know much Python, but I did create a reasonably large Google AppEngine project with it and learned as I went. I ended up liking Python a lot, but there are big holes in my knowledge. I’m glad I started with the simple AppEngine webapp framework instead of Django because I could see how the pieces fit together more easily. But now I’m ready to move up.
Django is a high-level Python web framework that encourages rapid development and clean, pragmatic design.
That’s Django’s “elevator pitch”. Django came out of a small, family run newspaper in Lawrence, Kansas. That’s pretty interesting for such an important web tool.
We start by actually creating a Django application that will eventually be something useful. The finished example application is online at cheeserater.com. It’s as easy to start as rails:
django-admin.py startproject cheeserater cd cheeserater manage.py runserver
And it starts a development web server on port 8000.
Models: this is one of the pillars of MVC, of course. And we won’t be using SQL to define or manage them, also of course. The speaker makes a great point that one of the (many) problems with SQL is that it’s not very compatible with version control. Just doing an svn update on your working copy isn’t going to really update it. It’s still a copy, but it’s probably not still “working”!
Since Django models are Python code, they’re managed like all your other code. But the code can also manage fixing the database structure when the code changes, just like Rails migrations. Django doesn’t have migrations, but you can do the same thing manually in it.
Unfortunately, the example application is pretty boring to me, and it uses unreleases Django features so I can’t play along with it. The framework is powerful and straightforward, but just watching it isn’t as interesting as getting into yourself.
Now Jacob’s going into a rant about URL design. It’s entertaining, and makes a good point: the URL should be designed from the user’s point of view, not the developer’s one. So nothing like fetchpage.cgi?number=72. Instead, it should be something like electioninfo. Oddly enough (to me) newspapers are particularly bad at this.
Anyway, this means that Django doesn’t specify your URL structure for you, that’s your job. I like that. The Rails idea of one right way to do things often appeals to me, but not with the URL structure. So with Django (and Google AppEngine) you give a list of regular expressions, and the first one that a URL matches is paired with a handler for the URL.
The rest of the tutorial covers the all the different pieces of the framework. There’s a lot of detail, but conceptually there’s little new here for me. And once again, I got a lot more out of the first half of the tutorial than the second. I don’t seem to be able to absorb more than an hour (or maybe an hour and a half) of material unless I’m actively working with the material. I can’t just watch.
Charles Engelke's Blog 