Class based views

Created: May, 31 and last updated: May, 31

We discussed these at a recent Vancouver Django (May 2009) meetup and it was also a pattern I used on a recent project.

Traditionally in Django a URL points to a function. So something like this is probably what you familar with:

from django.conf.urls.defaults import patterns

urlpatterns = patterns('',
    (r'^hello-function/$', 'recipe_9.views.hello_function')
)

And a view that looks like this:

from django.http import HttpResponse
        
def hello_function(request):
    return HttpResponse("Hello world!")

As it turns out, Django only needs something that is callable, so this can be a class. Let's just show the difference. The URLs:

from django.conf.urls.defaults import patterns
from views import hello_class

urlpatterns = patterns('',
    (r'^hello-class/$', hello_class()),
)

The class:

from django.http import HttpResponse

class hello_class:
    def __call__(self, request):
        return HttpResponse("Hello world!")

Oh and let's not forget some tests to prove this works:

from django.test import TestCase                
from django.test.client import Client

class tests(TestCase):
    def testFunction(self):
        clt = Client()
        res = clt.get("/hello-function/")
        assert res.status_code == 200
        assert res.content == 'Hello world!'
        
    def testClass(self):
        clt = Client()
        res = clt.get("/hello-class/")
        assert res.status_code == 200
        assert res.content == 'Hello world!'

What's the advantage of this? Well since it's a class you get all the advantages of being a class, doing things on the __init__, subclassing, overriding the __call__ and so on. Let's take an example. An extension of the Kenyan project for me recently was a similar project in another country. Similar, but of course, not the same. There were differences in the text and how certain situation are handled. So I made all the views point to classes (at this point I will add I also altered our URLResolver)... anyway all the requests in these projects do that same thing:

• parse the user input into a form
• validate the user input
• process it
• return an response

This logic of processing the request in this order has been pushed into a class. All my views inherit from it. So now the code for country X only deals with the specific parts for that country. When I add country Z to the mix, I just need to change the specific parts for that country.

Whilst this may sound a bit specialised, many applications can use this. For example one of the first applications I have takes every request and then checks the account information on that request (it doesn't use session for other reasons). So the first line of every view is a call to go and get that information. Making a part of template request processor sort of works, but you have to do work to dig that back out.

In the end making it a class based view adds only about 3 lines of code but makes you app much more reusable and adaptable in the future.

References:

• Simon Willison in his talk at EuroDjangoCon 2009

Comments

There are no comments.