I’m currently building a custom multi-blogging application in Django, and one of the challenges I ran into when developing the admin section was how to restrict users to seeing and editing only their own data.

Imagine the following (simplified) models:

class Blog(models.Model):
  owner = models.OneToOneField(User, primary_key=True)
  title = models.CharField(max_length=32)


class Entry(models.Model):
  blog = models.ForeignKey(Blog)
  slug = models.SlugField(max_length=255, db_index=True)
  headline = models.CharField(max_length=255)
  content = models.TextField()


If I want to show the user only their own entries in the admin object list, I can filter the list in the ModelAdmin.queryset method — simple as pie:

class EntryAdmin(admin.ModelAdmin):
  def queryset(self, request):
    qs = super(EntryAdmin,self).queryset(request)
    return qs.filter(blog__owner=request.user)


Now, say I want to also limit what blogs the user can assign the entry to. There’s a useful little ModelAdmin method called formfield_for_dbfield, but it doesn’t receive the request as an argument. What to do?

Well, the ModelAdmin.get_form method does receive the request as an argument, and it gets called before formfield_for_dbfield. So let’s just put the request object somewhere that we can get to it later:

class EntryAdmin(admin.ModelAdmin):
  def get_form(self, request, obj=None):
  self.request = request
  f = super(EntryAdmin,self).get_form(request, obj)
  return f


Then when we call formfield_for_dbfield we have easy access to the request:


class EntryAdmin(admin.ModelAdmin):
  def formfield_for_dbfield(self, dbfield, **kwargs):
    if dbfield.name == 'blog':
      kwargs['queryset'] = Blog.objects.filter(owner=self.request.user)
    return super(EntryAdmin, self).formfield_for_dbfield(dbfield, **kwargs)


Not the world’s most elegant solution, but simple and effective. And there’s plenty more you can do with these techniques. Gotta love Django!

Since word on the mailing list is that development versions are not only quite stable, but actually recommended over the stable version, and since I don’t have any deployed apps to worry about breaking, I thought it would be better to upgrade now than later.

Even better, this will make future upgrades as simple as a single subversion command (and, well, some fixes for incompatibilities, but that would be the case anyway, and probably worse if I weren’t to keep up).

I was a bit scared about the upgrade, but it turned out to be much much simpler than I anticipated.  I found a thread on the mailing list about doing just such an upgrade.  It wasn’t very explicit, but when I extrapolated from it, it worked.
Here’s what I did:

1. located my main django directory (had to search for it – it was inside an egg in site-packages), and renamed to django.bak (instead of deleting… in case of emergency).

   If you installed using DarwinPorts, like I did, the location is probably something like:

   /opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/Django-0.95-py2.4.egg/django

2. created a directory for the new installation (anywhere your user has read, write, and execute permissions will do, it seems), and cd-ed into that directory
3. ran

   svn co http://code.djangoproject.com/svn/django/trunk/ django_src

   and

   ln -s `pwd`/django_src/django /PATH/TO/SITE-PACKAGES/django

   (substituting the correct path, of course — in my case, /opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages)

4. Chose a good place on my $PATH to symlink to django-admin.py, and ran

   sudo ln -s ./django_src/django/bin/django-admin.py /DIR/ON/PATH/

   (I dropped it in /opt/local/sbin, since DarwinPorts had added that to my path, and I preferred adding something there to putting it on a main system path.)

And… everything’s up and running, at least in terms of the development server (I hadn’t set it up to run on Apache in the first place — I don’t know if that would complicate things).

Simple, huh?

Quick-n-Easy Comments

First thing I did was to replace the commenting system I’d created for my blog-app-in-progress with the commenting framework that comes for “free” with Django.  It’s not as fully featured as I might like, but it’s got some pretty nifty options, and is fairly easy to set up.  I figured I’d rather know how to use this than re-implement comments any time I want to add them to an app.

There are some interesting ways to extend the functionality of Django’s comment framework, although I don’t really like that they require editing the original source of that framework — especially since Django itself is likely to require upgrading frequently in the near future as we approach v.1.0.  Hopefully either the comments framework will be expanded further, or the model inheritance branch of Django that I’ve heard rumors of will eventually make that much less of an issue.

Absolute URLs

One thing I discovered was that the comments framework requires that the get_absolute_url() method be defined for any class that takes comments, so I took this opportunity to replace all the paths in my app with get_absolute_url() calls.  Except for the paths in the date-based generic templates, since a date object doesn’t have an absolute URL method.

I ended up adding some more global variables to settings.py, and constructing all the URLs from those, including the ones in urls.py and in the get_absolute_url() methods.  This should make future changes to path structure much simpler.

Templates

Lastly, I wrapped everything in the blog in the base template (after troubleshooting a problem with context not passed from a custom view to a custom tag), added a template tag so I could include a date-based archive menu in the sidebar, and set up some very basic design elements in a stylesheet in the header, to visually separate the sidebars from the content (I think this will make development a bit more pleasant).

All in all, not bad for another 4 hours or so of work in an unfamiliar language and framework.  I’m very pleased with how easy it is to develop in Django, although I’m still extremely frustrated at times with documentation that fails badly to describe syntax (I’m not talking about Python syntax only, but also which optional function arguments should or shouldn’t be in a dict; or syntax for Django’s template language).

I’m also pleased that I’m feeling better.  I might even venture to add chicken soup back into my diet tonight!

So, to my understanding, a decorator is a function that gets wrapped around a second function.  When the second function is called, the decorator is effectively called instead, and it calls the second.  I could be completely misled, but I’m going to run with that for now.  If I’m wrong, won’t someone please please please correct me?

My previous praise of the documentation was a little premature. The docs are a thousand times more approachable than RoR’s, and better categorized and stuff. But they’re very lacking in descriptions of syntax, or real-world examples, and in a few cases are out of date.

I spent 2 hours trying to figure out how to get date-based generic views to work before realizing that the examples I was finding on Google (unfortunately there are none on the Django docs wiki) were all a year out of date, and the view had to be called completely differently. And then it was only by chance that I finally managed to stumble across an up-to-date example of the correct way to call them.

Still, I feel like I sort of understand how the framework functions, which is more than I can say for RoR. I’ll probably be sticking to this. Once I sort out a few last questions, I’m going to need a more ambitious project to try!

I’d actually gone a bit further with Rails, beginning an attempt at writing an app, and then pulling up short for lack of clear documentation on working with many-to-many relationships, but that was a while ago, and the docs are a bit better now.

One thing that’s clear both from the types of tutorials they give and from the structure of the frameworks is that they were developed for different purposes.

Django was, as it claims, created for developing CMSes for content-heavy sites. It’s super easy to display content, and you get an admin interface for free (not to mention permissions tables for your database), but if you want end-users to be able to interact with the site, you have to develop your own methods for updating data (although the framework does the grunt work for you, and you just have to assign variables and then object.save()).

RoR was meant for “Web 2.0″ sites where the content is supplied by the user, and the whole purpose of the site is for the user to interact with the data. You get an end-user interface for data manipulation for free, but setting up users, permissions, and any sort of admin interface requires developing something from scratch or choosing one of a zillion plugins.

I have to say that while RoR is more trendy and has a lot more momentum right now, Django seems more mature. I like that it’s easy to understand how and why things are being accomplished, and that there appear to be generally accepted best practices in a lot of areas instead of the dozen different people’s plugins, each with pros and cons, to patch each oversight in RoR.

Of course, this opinion may change as I dive a bit further into Django. If it does, I’ll let you know.

I decided a couple weeks ago that I wanted to learn Django as well as Ruby on Rails. Django is a little bit less trendy, but seems to have more flexibility, and gives you an entire admin section of your app “for free”, as opposed to RoR, for which there are a zillion different ways to hack on user management, and no sense of “best practices” for a novice.

Django requires an up-to-date installation of Python, and a number of other dependencies, including a database API for Python. The best installation instructions I could find for OS X (one of the reasons I use a Mac is the availability of all these great UNIX tools that are so useful for a webmaster) recommended using DarwinPorts (soon becoming MacPorts) to simplify installation.

DarwinPorts is awesome.

Getting the Latest Apache / PHP / MySQL

I peeked through the list of available packages, and decided that as long as I was at it, I might as well add an Apache 2 / PHP 5 / MySQL 4.1 server to run on port 81 alongside the default Apache 1.3 / PHP 4 / MySQL 4.0 that I already had on port 80.

An earlier attempt to do this had run out of steam as I realized I would have to choose, locate, configure, and compile all my Apache modules by hand, which is really beyond my ability and ambition. But DarwinPorts would allow me to install Apache with a whole bunch of common modules included, and would download and install all the dependencies for each one automatically.

Well, even on my top-of-the-line-a-year-ago machine, this stuff takes a while to compile, but about an hour later (after cursing at myself for misunderstanding the sudo -u mysql command as running MySQL and trying to fix an error by prepending a path to the username) I had a working secondary server. DarwinPorts not only installs dependencies for each piece, and not only configures everything for you, and not only reminds you of changes to make to your $PATH variable in case the installer couldn’t, but sometimes it even tells you what commands to run after installing each program to properly do things like initalize databases. Sweet.

Here’s how you do this:

1. port install mysql4 +server
2. port install apache2 +server
3. port install php5 +mysql4 +apache2
4. copy httpd.conf.sample to httpd.conf
5. [optional] change path in DocumentRoot and associated directives
6. [optional] change Listen 80 to Listen 81 (If you want to run side-by-side with an Apache 1.3 installation on port 80)
7. add the following to the directive:
   AddType application/x-httpd-php .php
   AddType application/x-httpd-php-source .phps

Don’t forget to follow the extra directions DarwinPorts gives you.

Python, PostgreSQL, and Psycopg Spell Problems

I easily updated my Python installation, and then I ran into trouble. You see, the instructions I had for DarwinPorts were for installing with SQLite. I wanted to use PostgreSQL, partly because I figured it would be a useful thing to learn, and partly because skimming the initial tutorial and its comments had showed me that PostgreSQL was perhaps the optimal database choice because of its handling of foreign key constraints.

The main installation instructions for OS X used PostgreSQL, but compiled it by hand.

So I decided to wing it. The DarwinPorts available ports list included three versions of the PostgreSQL package, so I picked the latest one (postgresql81), and installed it. Then I installed the next dependency (py-egenix-mx-base). No problem. And then I ran into the final piece, psycopg.

Psycopg is a package that allows Python to interact with PostgreSQL databases. The instructions were very specific about installing version 1.1, not version 1.0 or 2.0, of psycopg. Great. I asked DarwinPorts to install psycopg.

Well, first problem: the DarwinPorts psycopg package depends on the postgresql8 package, not postgresql81.

Second problem: every server from which it attempted to download postgresql8 timed out.

I was a little bit flummoxed at this point.

I backtracked, downloaded the source code for psycopg, compiled it by hand using the main OS X installation instructions (I had to tweak a lot of paths to reference DarwinPorts’ installation locations), and boom! I’m off and running.

Phew.

I feel like an idiot for not documenting the exact commands I used, for the edification of future generations. If I ever do this again and am not running down blind alleys looking for solutions to problems caused by my own typos, I promise to do so faithfully. In the meantime, here are the steps to do it the easy way (assuming the postgresql8 servers are working):

1. sudo port install python24
2. sudo port install postgresql8
3. sudo port install py-egenix-mx-base
4. sudo port install py-psycopg
5. [optional] sudo port install subversion (If you’re using the development version of Django, or just want subversion)
6. Install Django

Next up, I’ll tell you what it’s like to jump from MySQL to PostgreSQL, and all about my experiences with the Django tutorial.