Must-Have Django Apps

A while ago fellow python-lover Adam asked me which modules I recommend for new Django projects.

Can’t-live-without-it apps

South

If you use Django and you’re not using South then you’re enduring way more pain than you have to.  South manages your schema changes for you, such as adding fields to existing models.  There’s really no reason not to use it.

Django-debug-toolbar

The Django development server prints a lot of information to the console, which is great for checking stack traces.  But you need a summary view to check for trends, and django-debug-toolbar does just that.  The app writes a bunch of information to the page rendered by Django (you configure when it appears, so your users don’t have to see it).  My favorite is the SQL section:

The grayed out area is the sql executed.  It gives you the nice waterfall on the right, and you can expand a query to see a stacktrace of the originating code. Very cool.

Django-registration

Nearly all web apps need a registration component – and if there’s one thing I can’t stand, it’s writing code that someone else has written.  Plug this app into your Django project and poof! – instant user registration.

The logic for the steps the user goes through to register (fill out form, click link in activation email, etc) is contained in it’s default backend.  Don’t like the default logic?  Just create a new backend.  I’ve found the app to be extremely flexible.  In Convey most users sign-up using the default backend, but if a user invites someone else then the invited user goes through a special Invite backend that I wrote.

Django_compressor

Every web app needs a strategy for optimizing its static content, JavaScript and CSS.  Two techniques that everyone should be using are minification and combining of assets.  Together, these strategies reduce the total number of bytes transferred from your server to the client and the number of connections to transfer all assets.  Of course,  you don’t want to combine or minify during development because that would make your life (much) harder.  Instead, use one of the many apps available to help you use these techniques in production.

I like django_compressor because it’s explicit – I wrap assets in my template with a special tag that tells the app that it should do it’s magic if DEBUG is False.  It DEBUG is True (such as on my local environment) then it does nothing.  This is really a matter of personal taste – take a look at your available options and the pick the one you like best.  But be sure to pick one!

Often useful apps

Django-reversion

Many projects need a history feature so users can see previous versions of their content.  This is similar to the ‘Revisions’ feature in WordPress.  If you find you need this feature take a look at django-reversion.  It’s easy to setup and will handle saving the versions for you – freeing you up to focus on displaying the versions.

Dajaxice

I considered not listing this app because although I do use it a lot I feel guilty about it.  The app’s tagline is “easy to use AJAX libraries for django”, which is why I use it – it’s easier than vanilla AJAX.  But it just doesn’t feel right.

Let’s say you have a page in a Polls app that needs to asynchronously update a poll’s title.  With Dajaxice the client-side code could look like this:

Dajaxice.polls.update_title(function() {
    alert('saved!')
}, {'id': 1, 'title': 'New poll!'});

The server-side code would be stored in a special file called ajax.py in your app.  Functions with the @dajaxice_register tag are available on the client:

@dajaxice_register
def update_title(request, id, title):
    #do stuff here
    return "success!"

The things I take issue with are:

  1. Dajaxice namespacing on the client.  I don’t like sprinkling the detail of which AJAX library I use all over my app.  What if I decide to change libraries?  This could be mitigated by aliasing the library, or wrapping it in a thin AJAX library of my own.
  2. Vanilla Django requires putting AJAX logic in the same place as other requests – in urls.py & views.py.  I don’t mind skipping urls.py but I don’t like having my AJAX business logic in a different place from the rest of my view logic.  Dajaxice thinks this is a feature, because there shouldn’t be presentation logic in a AJAX function.  But I would rather be consistent with the rest of the Django community on this one.

Awesome (but not Django)

Twitter-bootstrap

Twitter-bootstrap has been getting a lot of attention lately, and for good reason: it makes you app look great very quickly.  It’s also easy to configure when you’re ready to invest time into giving your app a unique look.