Two Scoops of Django

I recently bought the beta of Two Scoops Of Django based on all of the good reviews and recommendations it's getting fro people who know way more about Django than me. I haven't read it all in depth, but I've read most of it and at least glossed over the rest and so far it was well worth the $15.

The explanations of how and when to use the Class Based Views were excellent. The official documentation hasn't been very clear on them, so I've avoided them. In my personal case I still think they're mostly too much effort, but at least I could use them if I wanted to now. That leads me to another thing that I really liked. The authors gave their opinions, but they also gave thoughts and opinions of other leaders in the Django community and experts which weren't always exactly the same as their own, showing that there frequently are multiple valid ways to use Django that can work well.

One of the more interesting bits from the book is their warning against using multiple table inheritance in Django. This is something I've used several times because it worked really well. I had looked at the code and the sql queries it generates and knew it was doing some kind of nasty things, but so far it hasn't been a problem for me even in fairly performance critical pieces of code. I can see how it could go horribly wrong though and in the future I will probably see if there's a sane way to do what I need without multiple table inheritance. I may even go back and rewrite the bits of Djukebox that use it to just use and abstract base class instead.

The book also made me feel good in that some of my beliefs about how to use Django are in agreement with the authors. Those would be that replacing core components of Django isn't worth the trouble and that heavily modifying the admin interface also isn't worth the trouble.

When you swap out core parts of Django such as the template language or the ORM, you tend to break features of the system. You also are taking what was previously a cohesive system with parts all designed to play nicely together and throwing in some new part that doesn't care about Django and that Django doesn't care about and so may not work as well and at any point in the future may stop working.

As to the admin, the authors' and my feeling is that it's usually easier just to write your own custom control panel. I love the django admin for my own usage and as a layer for developers and knowledgeable admins to see things before having to actually log into the database directly via console. It gets clunky very quickly when trying to make it usable for others, though. My feeling is that this is because it's model based rather than workflow based. When creating a custom admin you can tailor it to the workflow, making that smooth, rather than having to edit and add potentially several models in clunky, occasionally confusing ways and in just the right order that you have to know ahead of time or heavily modify the admin UI to make not have those issues. The admin UI also has a few problems that have really caused me trouble. The primary one is that it does a SELECT COUNT(*) FROM table for the list view and there doesn't seem to be any way to stop it. On large tables this can make it slow or even impossible to get the list view to load, which makes it useless. The other is that fields that are not editable are impossible to make appear, even as read only, in the admin. This has mostly happened to me with auto_now or auto_now_add fields. Sometimes I want to be able to view those.