Django URL Dispatcher

Django has a nifty url dispatcher which allows you to direct requests from a url to an event handler in the form of a callable object in python.  If you followed the tutorials, your code is now probably littered with functions.   You can also use classes for event handling as follows.

from django.http import HttpResponse
from django.template import Context, loader
from scibrowser.web.widgets.form import FileLoader
from scibrowser.resources.fixtures import gdf
from scibrowser.lib.parsing.gdf import GDF

class Handler(object):
    def __init__(self, template=None):
        self.template = loader.get_template(template)

    def __call__(self, request, **kwargs):
        handler = getattr(self, "event_%s" %request.method.lower(), None)
        return HttpResponse(self.template.render(Context(handler(request))))

class GraphHandler(Handler):
    def __init__(self, template=None):
        self.file = gdf
        self.form = FileLoader()
        super(GraphHandler, self).__init__(template)

    def event_get(self, request):
        return {'javascript': GDF().json(self.file), 'form': self.form}

    def event_post(self, request):
        self.form = FileLoader(request.POST, request.FILES)
        file = gdf
        if self.form.is_valid():
            file = request.FILES['file'].read()
        return {'javascript': GDF().json(self.file), 'form': self.form}

Then, in the urls file you can have the dispatcher call the handler as follows:

from django.conf.urls.defaults import patterns, url
from scibrowser.web.graph.views import GraphHandler

urlpatterns = patterns('web.graph.views',
    # Example:
    url(r'^$', GraphHandler(template='graph.html')),
    url(r'^fd/$', GraphHandler(template='fdgraph.html')),
)

Interfaces and you

As you all know, I’m working on engineering a computational ethnography tool known as scibrowser. The problem is, I have any one of a number of databases I need to support; I need changes to the database side to not affect much of the main program.

Consider the above image. IQuery is an abstraction, an interface, which defines which methods the IQuery classes must implement. This common interface will have methods which fetches the stuff from the database our metrics class needs to calculate its stuff. This means our metrics methods are dependant on the abstract interface, not the actual databases. So now, pretend we have to support a new database. With this model, we no longer have to modify our metrics class at all; we never have to touch it. We simply have to add a new Object which implements the IQuery interface, and pass it to the metrics class in the form of a parameter.

The proper term for this is coupling and cohesion. A highly coupled class has a lot of dependencies, which makes extending functionality a real pain. A class that is not cohesive is one which has too many responsibilities. This basic principle helps with both of these, by reducing dependencies to one abstraction, and reducing the amount of extra, non related stuff we are forced to put into metrics to attempt to support one of a number of different databases.