Django Admin – An introduction and then applying a textarea instead of a text input

Well I thought now was as good a time as any to make my first Django post. One of the best things about Django is its automatic admin interface, built very effectively from just your model objects in the ORM. What a good idea. Generally, even if a webapp isn’t there just to do CRUD, its backoffice tool almost certainly is. And even the most beautiful webapps generally have awful backoffice tools. Why? Because who the hell wants to spend their time writing a boring CRUD interface 3 people are going to see! And when does business even consider time for that sort of thing, non-customer-facing mean non-thought-about.

Here’s an example of the backoffice tool for What Ales You:

Choose beers Edit a beer


Pretty isn’t she (I presume admin interfaces have the same gender as ships?). To activate the admin interface ensure under settings.py that django.contrib.admin is included under INSTALLED_APPS and that in urls.py you have the relevant lines (they are marked with comments) included and uncommented. Then add a file called admin.py to each project where you wish to administer model objects. For example, mine for my beer project is currently:

from alephile.beer.models import Brewery, Beer, BeerRating, Media, BeerComment, UserProfile
from django.contrib import admin

admin.site.register(Brewery)
admin.site.register(Beer)
admin.site.register(BeerRating)
admin.site.register(BeerComment)
admin.site.register(Media)
admin.site.register(UserProfile)

This tells Django which model objects I want to be able to edit. You’ll notice that my beer description is a normal text input which is a bit annoying, what I’d prefer is a textarea. To achieve this I need to add a ModelAdmin and a ModelForm. The ModelAdmin is a class telling Django how to administer a particular model object. Each ModelAdmin contains a ModelForm which tells it how to create the editing form. By default this just includes all editable fields, but now we are going to override the ModelAdmin and tell it to use a custom form instead. We end up with:

from alephile.beer.models import Brewery, Beer, BeerRating, Media, BeerComment, UserProfile
from django.contrib import admin
from django import forms

class BeerModelForm( forms.ModelForm ):
    description = forms.CharField( widget=forms.Textarea )
    class Meta:
        model = Beer

class BeerAdmin( admin.ModelAdmin ):
    form = BeerModelForm

admin.site.register(Brewery)
admin.site.register(Beer, BeerAdmin)
admin.site.register(BeerRating)
admin.site.register(BeerComment)
admin.site.register(Media)
admin.site.register(UserProfile)

and an interface that looks like so. Easy when you know how but something I initially struggled to find out.

A better description field

What Ales You

What Ales You Logo

Just a quick post to explain my lack of updates recently, I’ve been building another site in my spare time called What Ales You.

Conceptualised, designed and developed all by me, it’s a beer rating site (actually my girlfriend did the logo and name to be fair). Anyone can add, comment on and rate beers. It was written in Django, an amazing Python based web framework that takes the “convention over configuration” concept even further. In roughly 10 evenings I’ve built a site in a language I didn’t even know, impressive stuff. While some of that might be my genius, at least partial credit has to go to the excellent features of Django.

Technology ADD – On Django and Python

I seem to be suffering from a form of ADD recently. Hopefully it’s not the kind I’ll need Ritalin for although I haven’t actually checked with a doctor yet. But this is a special kind of ADD, technology ADD.

After living a lifetime stuck in a bit of a technology trap, using what everyone else seemed to be using and what recruiters wanted to see on your CV I’ve suddenly been opened up to a world of promising technologies. In the past month I’ve not only carried on writing in Ruby on Rails but have also started using Django, a full on web framework which is powered by Python.

A lot of people, my previous self included, would tend to call these new web frameworks lightweight and not suitable for really serious applications. I still haven’t quite made my mind up if this statement holds any merit but maybe a better question would be does the application you are working on have to be “serious” anyway. By serious here I mean seriously built. Does it need to scale horizontally at the flick of a switch, will you be dealing with billion row tables and processing 6,000 requests a second? They’ll probably answer that one day they might. That’s true, although only if they manage to launch without sucking up their funds building a project in a serious fashion.

Case in point about two years ago I tried a personal project in Java. Java’s what I know best so it seemed a sensible option. Professionally I work on a robust codebase with a great Spring / Hibernate base, full on integration testing, custom authentication code and a beautiful Ant based build environment. But I also forgot that the environment took 5 smart people 2 months to set up. Admittedly I now knew the general setup but it was hard work being disciplined and trying to write so much from scratch, in my SPARE TIME. The initial setup must have taken 6 months. I had lost all enthusiasm for it by that point.

Two weeks ago I started a project in Django. I didn’t even know Python. In a week of spare time work I’ve got a fully working database model, authentication framework, frontend with templating. I’d estimate I might have spent about the same time drawing pretty pictures for the frontend as writing backend code. That is truly astounding. I was impressed with Ruby on Rails but this is another level. Webapps can be coded in less time than it would take you to draw a UML diagram or database hierarchy.

The best thing is it has brought back my enthusiasm and hopes for personal projects. When writing something in your spare time, the best thing you can do is finish something. Don’t obsess over perfect theoretical programming practices, scalability and how you’re going to track sessions across multiple servers when you haven’t even got something launched. Obviously if you’ve got £1,000,000 and know your app is going to be huge, build everything as well as you can. For the rest of us I’d suggest speed is the more important factor.