Django Projects

I haven’t posted in a two years. I don’t know if anyone is still following my blog or not, but if you are. Hello and thanks for your patience.

These last few years I’ve been doing a lot of django contracts. It seems like every man and he’s dog business wants a django website to do complicated things involving user data. And django has matured in the last few years to become more sensible and consistent.

I remember back in 2009 talking with a developer about migrations support and how django had really let us all down by not really having it’s own migration framework built in. Now though, we have what is a pretty good (but not perfect) migration system.

These are some of the things that I have to do for many of the django projects I work on.

  • django-autotest – A way to run the testing framework over and over again without re-creating the database schema, auto rerun on file changes, shell title bar status updates, some nice base test extras like getting objects, making requests and setting up sessions which often crop up in test code. (include useful haystack base tests too)
  • django-fast-fixtures – A wrapper for dumpdata and loaddata to have media in fixtures. Useful for those statuses with icons and those tests with media files.
  • cache middleware – Caching middleware. When using django-cms, it’s VERY important to use the full page cache. Without it, your site is dead (or at least inkscape’s website would be) I’m still working on the expiration logic for all object types.
  • django-cats – I’ve been trying to convert my haystack/django category and search view into it’s own module. So far, it’s in a collection module I’ve used with multiple projects. The basic idea is that you can make a view that can slice up a queryset into multiple categories and haystack searches. Categories provide counts and easy to display and link iterators for templates. As well as the handy automatic haystack attribute creation and url key word support.
  • settings and admin tweaks – Most sites need a local settings template. This is because django doesn’t yet seperate out developer configuration from sysadmin configuration. So we still have to do it manually. It also doesn’t allow admin sites to be designed/changed, these two are taken care of in these standard patterns.
  • urls.py – And lastly is url_tree, a two line addition that ends up in almost all of my urls.py files as it’s just so useful. Take a look at the complexity of this urls.py, it’s made a lot more understandable by reducing the three calls into one simple call. Sometimes I tweak it to allow the view module name in too, but it’s mostly never needed.

What have you been up to in the last few years?