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.