jvoorhis

edit

First impressions of Django

Posted by Jeremy Voorhis Mon, 15 Aug 2005 17:58:00 GMT

Disclaimer:

I have been developing with Rails for a few months now. I like it. I’m familiar with it – I even like to think I know my way around the class library quite well. That’s expertise, something I don’t have when evaluating a new framework. I am also getting to know Ruby very well, from structuring applications intelligently to metaprogramming. Conversely, I’m a total Python newb. I also interact with the Rails developer community on a regular basis, while having no experience with Django’s community in any way. In short, there’s no need to accuse me of being biased – I know I am :)

I also did not complete the Django tutorial last night. I got through part three and decided to leave the rest for tonight, but I’m reporting what I’ve found thus far.

---

Django is an interesting creature. It simultaneously provides a lot more and a lot less than Rails for different tasks. It also has some key differences in its philosophy that yield some interesting results. I will try my best to compare and contrast the two frameworks.

Key similarities

• MVC-style framework
• Database-independent object-relational mapping
• Template engine w/ embedded Ruby/Python
• Code generation scripts
• Tiny web server for development use
• Mechanism for routing URLs

Django’s big ideas

• Model definitions are complete – schema is derived from methods, not vice-versa
• The application generates the schema – this is currently possible with PostGreSQL, MySQL and Sqlite so you can theoretically change your database vendor with ease
• Dynamic admin – really nice CRUD screens are generated from the models, and they are related according to foreign keys. You don’t get that with scaffolding in Rails. The dynamic admin is available system-wide, with facilities for overriding the default templates
• Generic views – generic templates for details and list views are installed system-wide This is a lot like scaffolding.
• A project can have multiple applications which share a dynamic admin, but are responsible for their own configuration (routing, etc.). Yep – they’re pluggable.
• User and group models built into the framework, as well as history – when you create a Django project, you get the benefits of the login_generator (with salt), an ACL, and acts_as_versioned out of the box.
• The pluggable apps share the user model – single sign-in!
• Django provides other large application chunks, such as frameworks for RSS as well as comments. I haven’t used these yet, but I can see them being useful for providing these features on top of my models

My experience

The first few minutes spent in the Django tutorial were really rewarding. Specifically, the dynamic admin thing is cool. It demonstrates some attention to detail and from what I’ve seen so far, it’s the sort of thing I would feel comfortable giving to a client.

As soon as I left admin-land, however, I began to miss Rails. Views (Django-speak for actions in Rails) aren’t automagically associated with templates (Django-speak for views in Rails). Instead, you write the code to glue them together for each view, passing the output to an HttpResponse object. The template system also lacks one feature I couldn’t imagine using Rails without – helper methods. Instead, you get “filters” which you pipe your data into with, well, the pipe character. Filters seem useful for formatting data, but they don’t appear to be intended for complicated tasks. On the whole, Django’s templates remind me of Smarty more than ERb.

The directory structure for a Django application is smushed – in the tutorial, models are all written in one file. I could see this becoming a nuisance if I accumulated a lot of model code. Another thing I have seen no mention of thus far is unit testing. I would be surprised if there was no unit testing framework available in Python, though, so I’m assuming it shouldn’t be an issue if you want to test your models yourself. Unfortunately, Django has no concept of distinct environments, so it may take some additional hacking to get the isolation of the test environment that I enjoy in Rails.

One thing I am liking about the framework is the pluggable applications concept. A Django project has many applications, and there are project-wide configuration files – one for routing and another that is like environment.rb. These files are Python and are governed by a similar philosophy to Rails’ Ruby configuration files. Within these files, you can provide some global settings such as a database connection, and delegate other settings to the individual apps. For example, you can chomp the first part of a url and pass the remainder of it to the appropriate app, which then manages its own routes. This should make applications very portable between projects.

Tonight I plan to finish the tutorial, and then kick Django around some – specifically, I’d like to see how the dynamic admin and the sql generation can cope with more complicated domain models.