Related link: http://www.turbogears.org/
About a week ago, I said a few preliminary, positive words about TurboGears before I had a chance to actually do anything with it. Well, I’ve written some code now and I’m ready to report on all the ugly details.
I recently bought my wife a Canon EOS Digital Rebel. For various and irrelevant reasons, I created a simple little digital photo managment program for it with CherryPy and SQLObject. My little app seemed to work OK. Just like anything, it has some rough edges and some room for improvement. When Kevin Dangoor recently announced TurboGears, I decided to rebuild my little photo app using TurboGears.
My nonGears version is just under 300 lines of pure Python code. No templates. And I must say, it’s not the prettiest coding I’ve done. No templates means that I’ve embedded HTML in my Python code. I know. That’s nasty. But I wrote it as a quick and dirty job. The Gears version turned out to be about 300 lines of Python and 225 lines of templates. This really is not a fair size comparison because I added a few niceties in the TG version that weren’t in the VCP (vanilla CherryPy) version.
I started the project with the
quickstart option to the
turbogears-admin.py script. This did a nice job of creating the directories and files I would need. It separated out all the parts in a nice MVC fashion. The database model went into a
model.py module. The controller went into a
controllers.py module. And the view went into a
templates folder. This structure answers a whole class of questions for a developer about where to put which files and what to name them. Structure is good.
One thing that I had to get used to with TurboGears was writing code in the controller and then having to specify which template to “send” it to, then fleshing out the template. This is just an adjustment to an MVC structure. My original code didn’t have any of that; the HTML was inline. That made it easier to write initially, but a maintenance nightmare afterward. This logical separation made it really easy to re-use code (yes, I did re-use some code; I’m not talking abstract theory, here) and fix bugs while I was coding. Separation is good.
Probably my biggest hurdle was SQLObject. I need to thoroughly read the documentation. I created relationships between some of the tables which aren’t working as I would expect. I’m sure it’s my problem, but I just didn’t invest the time in working through it until it worked.
One of the really cool features of TurboGears is the
turbogears-admin.py shell commmand. It opens a Python interpreter with the
PYTHONPATH set exactly like it is for the running CherryPy process. This goes a long way in helping test code.
While I was not able to pound out my photo management app in 20 minutes, like Kevin Dangoor in the demo video, I felt very productive. Nothing was laid out in a non-obvious, surprising way. And - get this - I was having fun writing my little app. Fun!
I think TurboGears is an assembly of the right components. It answers a lot of the common questions developers will have in logical, well-thought-out ways. It is extremely easy to use. It has a growing community using and supporting it. I like what I see from technical, psychological, and sociological perspectives.
OK, now for the ugly details. My UI design is horrendous. I think it’ll take more than TurboGears has to offer to help me make a decent looking website. I think it’ll take something closer to a miracle.
Have you tried TurboGears? What are your thoughts?