Shifting Gears: Switching to Django

by Jeremy Jones

Related link: http://www.djangoproject.com/



When TurboGears came out, I was pretty excited about it. I was able to quickly throw together a digital photo management application for my wife. I was also able to quickly build her an online store for her new business. As is common with any technology, I encountered a number of problems while building my wife's store. There have been issues with the Kid templating system which still appear to be unresolved. Maybe they're fixed, I don't know. I modified my code to bypass what was causing the errors I was seeing - at a loss of functionality and flexibility. Another issue I've seen is with CherryPy deadlocking on what appears to be session file cleanup. I could switch over to database session storage, but I'm not sure I want to go that route. If I stayed with TurboGears, though I might not have to switch; I just read on the CherryPy list that this issue may be fixed.

Serendipitously, I recently started looking at Django. All of these issues and my glance at Django really got me thinking about how TurboGears was put together. I have had almost no problems with the TurboGears code itself. Actually, I can't really think of any problems I've had with core TG code. The problems I've had have been with the underlying components - specifically CherryPy and Kid. I began to wonder if I might be better off with a unified solution rather than a solution made of components from separate projects. So, out of curiosity as much as technological motivations, I began porting my wife's store to Django. I may be totally wrong about unified vs. multiple project component based, but my thoughts are at least reaffirmed by this blog post from David Heinemeier Hansson (the creator of Ruby on Rails).

The store consists of a product catalog, a shopping cart, a shipping calculation algorithm, and a payment system using PayPal. The most logical first step was to migrate the database model. From a user perspective, both SQLObject and Django take a common approach. A class corresponds to a table and class attributes (each with a certain declared type) correspond to columns in that table. The database migration was pretty simple. I did do a minor overhaul in how I group products together. I still have a little work to do on that, though. One huge plus to Django is the pre-built admin interface. With a total of two extra lines of code per class/table, you get a beautifully usable, customizable adminstrative interface to your database. I haven't utilized it much yet, however. In these initial stages, I find it easier to populate the products into the database through a script. But I think when the site goes live, this will be a huge feature in managing orders.

The next thing I did was to write a couple of quick pages to display the items in the product catalog. At this point, I knew that I was just experimenting and wasn't committed to using Django yet. I wanted to see how Django would run in my production environment, which is under FastCGI.

Let me take a small pause to say that much of my recent trouble with TurboGears would have been caught earlier if I had deployed it incrementally to my production hosting server (or probably to a comparable environment not on the hosted server). So, I blame myself for not catching the problems earlier. I did try at one time to get the store running under FastCGI on one of my own servers in a comparable manner to how it's run on Dreamhost (my hosting service). When I couldn't get it running in a timely manner, I decided to not pursue it any further. In hindsight, this was obviously a mistake.

So, back to my tale. I let this minimalistic site run for a day or so to see if I could feel comfortable moving forward with Django. Everything checked out well. There were no anomylous errors. Both the admin interface and my product listing pages were displaying consistently. (However, the admin interface is devoid of images or a stylesheet. I'll figure that out soon. I think it has to do with how I have my static/media mapped. I'm sure it's not a problem. Famous last words, right?) At this point, I became fully committed to porting the full store over to Django.

Next, I set up a base template that each page would extend. This will be a nice addition to the site since I was unable to use this same feature in TurboGears. This is one of the problems I generally hinted at above regarding the Kid templating system. I also fleshed out some of the static pages so I mostly had the same look and feel and content. That was a snap.

I decided that I should next start building up the code around the product catalog, getting all the images and product details displaying properly. Again, this was simple. Django's templating system is really simple and straightforward to use.

This is about as far as I've gotten. I'm hoping that I'll have the site totally migrated by next weekend. I'll post back with progress and thoughts on Django. So far, it's working pretty reasonably.

8 Comments

tazzzzz
2006-01-22 19:24:38
Reuse has its tradeoffs, but it's good on the whole
I'm sorry to see you switch to Django, but you do need to do what's required to get your project out the door. It's a shame that your deployment issues weren't solved in time. (I wish I had more time to help you through them... it would've been hard for me to even give advice, though, given that I don't have a Dreamhost account and I'm not familiar with all of the options available there.)


Regarding TurboGears' use of existing projects: yes, there are tradeoffs. We inherit whatever warts those projects may have. Of course, all projects have warts, whether they were created all at once or joined together. I think that the pluses of working with an existing community outweigh the minuses. I also think that some of what I'm planning to immediately follow TG 1.0 will show the power of the TurboGears model. Time will tell for sure.

nerkles
2006-01-22 20:28:32
apples and oranges
Comparing a non-released development version of one framework to a released, production-ready version of another? Whaaat?
adrian_h
2006-01-22 21:21:21
apples and oranges
Actually, Django hasn't reached 1.0 yet, so the comparison is fair.
vvictor
2006-01-22 21:22:41
django vs whatever
My opinion reading this article is that the author changed something that did not work with something that worked. He, like many other people in this world, does not care if his favourite tool was built using C or Java or if private variables were called m_XXX or _XXX or even myGREATEST_varIBALE_EvEr_XXX. He doesnt care about the version of the product he's happy to use. From my perspective reading this article I can only say congratulations to django team, they just found a happy user :)
jmjones
2006-01-22 22:13:22
Reuse has its tradeoffs, but it's good on the whole
I look for good things from TurboGears. I could not agree more with your statement that all projects have warts. There appear to be some in Django which they are working on (http://code.djangoproject.com/wiki/RemovingTheMagic) . I'm sure there are others. There are some things which I think TurboGears does better than Django. For example, project layout is much more straightforward in TG than it is Django. (This perception could come from my lengthy exposure to CherryPy, though...) But, Django's "quickstarted" projects seem a bit more flexible. I really don't know how Paste plays into this... It may level the playing field on that issue....
jmjones
2006-01-22 22:26:43
apples and oranges
Actually, one of the reasons I did not hesitate to use TG for a go-live site was the maturity of some of the underlying components. CherryPy is at 2.1.something. SQLObject is at (best I can tell) 0.7. Those were really the big 2 for me. I've used both of these for a while and have had nothing but good experiences with them. So, TG is built immediately on released production-ready code (version numbers notwithstanding). And as I mentioned in my blog, the problems I had with TG weren't with TG core. It has been with the components, CherryPy being one of them.


But was I trying to "compare" them? That's not what I was doing. Here's the gist of what I was stating: "I wanted to build a project with an all-in-one web framework. I had problems with TG, so I'm looking at Django now." Yes, I did want to make sure I didn't run into the same "gotchas" with Django that I did with TG. So, if there was a comparison, that was it. Perhaps I should have put another mea culpa in there about expecting TG to be production ready, but I don't think that's necessary. And I think it may be production ready for some folks.

elazutkin
2006-01-22 23:29:57
Missing media...
Try this link http://wiki.dreamhost.com/index.php/Django for setting up your Django project on DreamHost using FastCGI. If you need more help, Django users group (http://dir.gmane.org/gmane.comp.python.django.user) will help. (I am dreamhosted too).
nerkles
2006-01-23 05:22:12
apples and oranges
D'oh!