07 Dec 08 Anatomy of a Shoutbox; Part 2 – Model and Admin

One of the things that really attracted me to Django was that it has an ORM. Of course I had never seen an ORM before and didn’t even know that term until later. An ORM (Object-Relational Mapping) allows you to seamlessly create Python objects from database tables, and vice versa. So you never have to code your own SQL unless you really want to do something fancy.

For the shoutbox app, we need a very simple model. Here is my models.py file:

from django.db import models
from django.contrib.auth.models import User

class Shout(models.Model):
   user = models.ForeignKey(User)
   shout_date = models.DateTimeField(auto_now_add=True)
   shout = models.TextField()

   def __unicode__(self):
      shout = self.shout[:60]
      return u'Shout from %s: %s' % (self.user.username, shout)

   class Meta:
      ordering = ('-shout_date', )

There is nothing too out of the ordinary here. Each shout was made by a registered user, so we need a ForeignKey to the User table. We record the date and time the shout was made (using auto_now_add initializes this field for us when the object is saved), and finally the shout itself is just a TextField.

The __unicode__ function will be used in the admin interface. Here we just show who the shout is from and then a truncated version of the shout. Finally, we can tell Django our default ordering of Shouts is in reverse chronological order via the ordering attribute in the embedded Meta class.

Now we turn to the admin.py file to enable and configure an automatic admin interface for Shouts. Again, this is an amazing feature of Django that really sold me on the idea of trying this framework out.

from django.contrib import admin
from shoutbox.models import Shout

class ShoutAdmin(admin.ModelAdmin):
   list_display = ('shout_date', '__unicode__')
   raw_id_fields = ('user', )

admin.site.register(Shout, ShoutAdmin)

Here we derive a class from Django’s admin.ModelAdmin class to configure our admin interface. Our main display listing should consist of two columns: the shout_date and then the __unicode__ representation of each Shout. This will invoke the __unicode__ member function on each Shout object displayed.

Here I am using the raw_id_fields feature for the first time. Since I have over 2000 users currently on SG101, I do not want to load all that information into a select box everytime I drill into a Shout. The raw_id_field simply displays the raw user id along with the username. If I really want to change the user, the field has a pop-up control to allow me to load all the usernames. I should have done this on a few other applications I previously wrote. This is the constant refactoring I wrote about earlier.

And that’s it! After running syncdb I can now add Shouts to the database via the admin interface, all in less than 25 lines of code from me! In part 3 I will show how I display the shoutbox as a “block” (to borrow the PHP-Nuke term) on the website. To do this, I created one of my first Django template tags and incorporate some 3rd party javascript to accomplish the scrolling of the shouts. Stay tuned.

Tags: django, sg101, shoutbox