Richard Jones' Log: Django exploration
I ended up going with Django for the pyweek website. I looked at both it and TurboGears and ended up choosing Django because "D" comes before "T" in the alphabet. There really didn't seem to be much else significant between them.
I spent about an hour on Saturday scribbling down the data model based on the old Zope pyweek code, translating that into Django model code and playing with the auto admin interface. I then got bored and did something else.
This morning I decided to try to get the most basic requirements going (stuff I need to announce the new website): some basic page views and user signup. Seems easy enough, right? Heh.
I spent about half an hour confused because there's a Context and a DjangoContext (I'm sure there's a good reason, though for the life of me I can't see it).
OK, so on to user registration and details editing ... er ... "Use '[algo]$[salt]$[hexdigest]'" ... you're kidding, right?
Right. Some time later and I've hand-rolled user registration and details editing pages. I've not done the password reset email thing yet because that can wait (I'm not going to have a huge number of users). On to the simpler stuff: implementing the polling and voting systems I need.
Yes. I'm going to stop development in Django for now and switch to TG and see how I go in that.
No, back to Django. TG has identity management, *if* you use 0.9, and it's undocumented. I'll stick it out with Django, I think. At least I've got the user management stuff going in that.
Andy -- Yup, that stuff has all been fixed. You're right about Django being extracted from working code; that's the main goal for 1.0, is to remove some of the magic that's happened over the 2+ years we've been using it. Fortunately, we're making fantastic progress for the next version.
The thing with Django is that it's a framework that is being extracted from working code, hence some of the funnies like Context and DjangoContext. These things seem to be shaken out and resolved as the framework progresses towards a 1.0 release.
Frankly, what lost me was that in the model you can supply an alternate name for a database column (e.g. supplier_abn_code_id can be called supplierAbn) but *you can't use it*. That and a couple of other minor warts with Django's model sent me off in a huff. For all I know they've been fixed but I'm now playing with TurboGears, which has the advantage of having the rather marvellous SQLObject as it's ORM.