Peter M Howard ::

Winter with Django

02December2006 [webprog]
[tweet this]

The list of things I want to change on this site has just kept on growing for some time now. And it’s now reached a point where, combined with my desire to learn another language (no, not that kind of language), I’ve decided to do a complete ground-up rebuild. It does mean, though, that I won’t touch much on this site until I’ve got a bunch of areas working together nicely (though the intention is that the site will consist of modules that can easily be added and removed, so I could probably get the basics up and start plugging bits into it):

The cool kids are all using Ruby on Rails these days, so I played with it for a week to try figure out if it would suit my purposes. The complete lack of coherent documentation (ie, out of paying for a book, when I don’t even know if I want to continue with the language) was off-putting, and I’ve been hearing some buzz about Django for a while now. Took a brief look at it and I’ve fallen in love. The structure seems a little more elegant, the basics better-documented, and there’s a little more flexibility for working with database structures that don’t quite match the language’s expectations.

Where Rails is a MVC framework for Ruby, Django is similar, but for Python. The two base languages are fairly similar (though support for Python is wider and easier), but Rails tries to hide most of the Ruby, while Django has a straightforward/simplified template syntax, with support to drop into Python anywhere and at any time. The idea of the MVC (model-view-controller) structure is to separate business-logic and presentation, which is a thing of beauty, but Django takes it a little further, splitting the ‘view’ into Templates and Views. So the view is where I handle the presentation-of-data-logic, and the template is simply presentation - the idea being that a designer with no knowledge of the base language could build a Django template - all they’d need is a couple of field names. Breaking up logic and presentation also means there’s generally only one place to go looking when debugging… And, when I’ve been all about separating data and presentation already with XHTML and CSS, Django suits my mindset.

So I’ve been playing with getting Django working on an old CD-collection system I run locally on PHP; biggest problem is that Django doesn’t support composite primary keys, which is something I use in the database. (Rails doesn’t support them either, but I got as far as displaying the data in Django despite the key limitation, while in Rails I could barely start the application.) Fortunately I use primary keys the way Django expects them throughout wintermute’s system, so I’m hoping the database-interface will actually be easier. Working with a database it doesn’t like has taught me a lot about Django though, so it’s all useful… If I can’t get it working as-is, I’m just going to add a primary key field to the table that uses composites; will take a little work going through and adding IDs (talking a couple thousand rows here), but it may have to be done…

Changes are afoot.