First Impressions: TurboGears and Django
Posted by Y Ddraig Wen Sat, 05 Jan 2008 15:51:00 GMT
I've done a polls tutorial on Django and a wiki tutorial on TurboGears. I'm not ready to pick between the two yet. Both had things I very much liked and I'm too new to Python to make a snap decision. But here's a few things that I've noticed/liked/disliked so far.
- Both have an inbuilt admin area - Django's uses a password and is accessible in a subdirectory called admin. You specify what the admin interface should and shouldn't do with relation to your models and can customise it fairly substantially in a short amount of code. TurboGears' uses a different port rather than a password, it does a lot more in regards to the TurboGears setup but doesn't seem customisable with regards to models.
- Both have one controller file and one model file for the entire application with separate view files. This makes sense with Django which can have lots of apps plugged into an overall project, but could scale badly with TurboGears - although I suppose some form of importing might help.
- Django has a template language very much like Rails. TurboGears' is less familiar but does have nice code to replace the contents of an html tag with something generated by Python code. Both can use different templating languages if you wish.
- TurboGears uses MochiKit which is a javascript library for doing ajaxy stuff. Django doesn't seem to handle javascript out of the box but that could be the choice of tutorials.
- Both come with a web server for development purposes. The one in TurboGears kept stopping or crashing with bad code.
- To create or change SQL tables you write specific code in the model file and then run a script which then updates your database. Not quite the flexibility of migrations but pretty cool and at least it doesn't involve yet another file. Your attribute information is there in the model. With TurboGears sqlite ran straight out of the box, Django needed a little configuration.
- Django has some great "find" methods which will even redirect to a 404 if there's no model found. This has to do with exceptions in TurboGears.
- Django has some kind of hidden scaffolding for some of the common methods.
- TurboGears just returns a dictionary of variables which the template (@expose'd before the method) then uses. Django specifies both the template and the variables in a render_to_response method. Very similar but I feld the Django one a little more intuitive.
- Django uses regular expressions for urls (a bit like Rail's routes file but with reg exp). This is quite scary to someone who melts at the sight of a reg exp, however it's also very customisable. I have no idea what TurboGears does. I think it just looks for methods named after the page called.
