A Brief Django/TurboGears Comparison

   Print.Print
Email.Email weblog link
Blog this.Blog this

Jeremy Jones
Feb. 10, 2006 10:13 AM
Permalink

Atom feed for this author. RSS 1.0 feed for this author. RSS 2.0 feed for this author.

Here are a few thoughts that I have now that I've completed porting my wife's website from TurboGears to Django. This isn't intended to be a comprehensive list of differences between TurboGears and Django. Nor is it intended to assert superiority of one framework over the other. These are simply my thoughts and feelings regarding the two frameworks. That being said, my conclusion is that Django is a better fit for me.

1. TurboGears has a little bit faster hit-the-ground-running startup time because it creates all the files you need with a single command without having to run subsequent commands to create the application. This is a definite tradeoff, though. Even though it's another command to create an app (within a project) in Django, the flexibility of being able to have multiple apps self-contained in their respective directories is, in my opinion, worth the extra step.

2. TurboGears' directory structure and file layout is simpler than Django's. Again, the number and location of files and directories in Django is a direct result of the flexibility of being able to have multiple applications in the same project. I don't mind the slightly deeper directory nesting or the few more files in a new Django project (and app).

3. The template system in Django took a little bit to get used to. One thing that tripped me up for a while was Django's variable substitution does dictionary and attribute lookups, method calls, and list indexes all using a dot. I expected to access a dictionary's key using some_dict["some_key"], but instead, it's some_dict.some_key. And I expected to access a method by some_object.some_method(), but instead, it's some_object.some_method. This was clearly my fault as it is obviously documented here After getting past that hitch, I really like Django's templating system. It's really simple but powerful enough to do anything you want to do. Since you can't just execute arbitrary code in a Django template, it forces you to pass in the data you need from your view. This separation is a good thing. Unquestionably, in my mind anyway, Kid is a very powerful templating system. However, the ability to execute pretty much any Python code you want to from within a Kid template is a little concerning. And the requirement of Kid documents being well-formed XML can be a bit of a pain. And when you create one that isn't well formed, you don't always get back an accurate error corresponding to your Kid template. For example, here are the first seven lines of a Kid template which I intentionally mangled (line numbers supplied from vim):


1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://w ww.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
2 <html xmlns="http://www.w3.org/1999/xhtml"
xmlns:py="http://purl.org/kid /ns#">
3
4 <head>
5 <title>$A Brief Django/TurboGears Comparison<title>
6 <link type="text/css" rel="stylesheet"
href="/static/css/ppp.css"/>
7 </head>


Notice the mismatched title tag on line 5. The error I received was ExpatError: mismatched tag: line 7, column 2. A tag name would be more helpful here. And an accurate line number corresponding to the Kid template would be helpful as well.

4. Which leads me to the errors you get back from Django templates. They are excellent. If I try to access a URL that isn't specified in the urls.py file, I get a nicely formatted error page with the contents of my urls.py file that helps me see the errors of my ways. And if I have a syntax error in my code, I get a traceback and source code with highlights of the offending code.

5. I've really come to appreciate Django's URL mapping approach. URL->function calls are explicitly declared in the urls.py file. This allows me to easily create URLS that look like I want them to look and not have to hang one class off of another to create the nested structure that I may want. It also lets me create RESTful looking URLS if I so wish. Another benefit is that you get (for free) a "table of contents" of your site all in one file. TurboGears is a little more awkward to fashion your URLs the way you want them. I did read the other day that there is a package that sounds like it allows CherryPy to use an alternative URL mapping scheme which sounds more like Django, but I haven't investigated that yet.

6. Django's admin interface is really slick. I haven't been able to use it as much as I would like because it doesn't appear to be able to display nested data structures on a single page. For example, if I have a Customer data object which can have multiple CustomerOrder (as in, the customer has ordered some merchandise) data objects and each CustomerOrder can have multiple OrderItem (as in, individual pieces of merchandise in the order) data objects, I haven't found a way to display the Customer related to the CustomerOrder related to the OrderItems all in the same page in the admin interface. The last time I looked at CatWalk in TurboGears, it seemed like it was a pretty slick database browser, but not really geared for turning end-users loose on.

Jeremy Jones is a software engineer who works for Predictix. His weapon of choice is Python.