Den Grundstein zu Django [1] legten Adrian Holovaty und Simon Willison im Herbst 2003 während ihrer Arbeit bei World Online, der Web-Entwicklungsabteilung der World Company Lawrence, einem großen Verlag in Kansas, USA. Die World Company verlegt diverse Zeitungen, betreibt einige Websites und beschäftigt rund 600 Mitarbeiter. Das Flaggschiff ist die Tageszeitung Lawrence Journal World, die der Verlag seit 1995 auch online publiziert.

Um dem hektischen Alltag einer Nachrichtenredaktion gerecht zu werden, musste ein Framework her, mit dem sich auch in kürzester Zeit komplett neue Features in eine bestehende Website integrieren lassen. Holovaty und Willison fingen an, Code aus bestehenden Webanwendungen herauszulösen und in ein Framework zu überführen, das im Sommer 2005 unter dem Namen Django (benannt nach dem Jazz- Gitarristen Django Reinhardt) als Open Source veröffentlicht wurde.

Dieser kleine geschichtliche Ausflug hilft dabei, den Aufbau des Django-Frameworks zu verstehen. Django versuchte ursprünglich genau die Probleme zu lösen, die in redaktionellen oder inhaltsbasierten Anwendungen auftreten und tut dies besonders gut. Was nicht heißen soll, dass es in anderen Bereichen weniger gut geeignet wäre. Im Gegenteil: Mittlerweile hat Django einen Reifegrad erreicht, in dem es so gut wie jedes Problem in der Web-Entwicklung sehr elegant lösen kann.

Unter dem Namen Ellington [2] vertreibt die World Company übrigens ein auf Django basierendes Content Management System, das unter anderem von der Washington Post und der Las Vegas Sun eingesetzt wird.

Django ist, wie die meisten Rapid-Development-Frameworks, nach dem MVC-Prinzip (Model-View-Controller) aufgebaut, nur die Nomenklatur weicht etwas ab. Das Model ist auch in Django das Model, allerdings wird der View Template genannt und die zentrale Komponente, der Controller, heißt bei Django View und entscheidet, welches Model wann mit welchem Template dargestellt oder bearbeitet wird.

Ein weiteres wichtiges Thema bei der Entwicklung von Webanwendungen sind URLs. Viele Frameworks geben eine URL-Struktur vor, etwa in der Form „/controller/action/arguments“. Django lässt dem Entwickler hier völlige Freiheit. URLs werden in Form von URL-Patterns definiert, die einen regulären Ausdruck mit einem View assoziieren. Argumente können mittels des regulären Ausdrucks aus der URL geparst werden und werden automatisch als Parameter an den View übergeben.

(r'^entry/(?P<object_id>[\d]+)/$', myview, {}),

Eine Zahl in einer URL, die mit „/entry/“ beginnt, wird automatisch als Parameter „object_id“ an den View „myview“ übergeben.

Ein großer Pluspunkt für Django ist das mitgelieferte Admin-Interface, über das alle CRUD-Operationen (Create, Update, Delete) sofort erledigt werden können, nachdem die Datenmodelle definiert sind. Anders als bei vielen Frameworks handelt es sich hier nicht um ein Skript, das ein paar Dateien erzeugt, die dann verwendet und bearbeitet werden können, sondern um eine vollwertige Anwendung, die leicht erweitert werden kann.

Entwickelt man Webanwendungen mit Django, so arbeitet man mit mehreren kleinen Applikationen in einem Projekt. Idealerweise versucht man immer die einzelnen Applikationen so zu gestalten, dass diese wiederverwendbar bleiben und in anderen Projekten ohne große Anpassung eingesetzt werden können. Eine persönliche Website mit einem Blog könnte beispielsweise aus folgenden, in sich gekapselten Applikationen bestehen:

• Blog-Applikation
• Kommentar-Applikation (z. B. django.contrib.comments)
• Tagging-Applikation
• Applikation für statische Seiten (z. B. django.contrib.flatpages)

Die gesamte Verwaltung der Daten kann das mitgelieferte Admin-Interface übernehmen, da es sich im Wesentlichen nur um CRUD-Operationen handelt.

Bevor es los geht, muss Django installiert werden. Django ist ein normales Python-Modul und wird genauso installiert. Nach dem das entsprechende Release heruntergeladen ist, muss es entpackt und dann im entpackten Ordner mit „python setup.py install“ installiert werden. Dadurch wird Django im Python-Path platziert und das Skript „django-admin.py“ in den Path kopiert, so dass es später einfach auf der Shell ausgeführt werden kann.

Jetzt kann man sich mit „django-admin.py startproject t3n“ eine kleine Projektstruktur erzeugen lassen, um ein erstes Django-Projekt zu starten. „t3n“ ist hierbei ein frei gewählter Name für das neue Projekt. Das Script erzeugt einen Ordner „t3n“, der eine leere Datei namens „__init__.py“ enthält. Diese Datei sorgt dafür, dass der Ordner als Python-Modul benutzt bzw. importiert werden kann. Darüber hinaus befinden sich in dem Ordner drei Dateien: „manage.py“ – ein kleiner Wrapper für diverse administrative Funktionen von Django, „settings.py“ – eine Standard-Konfigurationsdatei für das Projekt und „urls.py“ – die Root-URL-Konfiguration für das Projekt.

Ein simples Blog (oder eher eine blogartige Anwendung) mit Django würde man nun damit beginnen, per „pyhton manage.py startapp blog“ in dem neuen Projekt eine Blog-Anwendung zu erstellen. Der Aufruf des Skripts erzeugt einen Ordner „blog“, in dem sich ebenfalls eine „__init__.py“ befindet. Dazu noch eine „models.py“ für das Datenmodell und eine „views.py“ für die Views. Als erstes erstellt man nun das Datenmodell für die neue Anwendung.

Ein einfaches Blog hat mehrere Einträge, die einen Titel, Inhalt, einen Autor und ein Veröffentlichungsdatum enthalten. In der „models.py“ sieht das dann so aus:

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

class Entry(models.Model):
	title = models.CharField(max_length=128)
	content = models.TextField()
	author = models.ForeignKey(User)
	pub_date = models.DateTimeField()

Registriert man nun das Entry-Model mit der Admin-Applikation (siehe Listing 3), kann man bereits beginnen, Daten für das Blog in die Datenbank einzupflegen. Bei größeren Projekten kann dies eine große Zeitersparnis bringen, weil schon redaktionelle Daten eingegeben werden können, während die Programmierer noch an anderen Teilen der Anwendung arbeiten.

from django.contrib import admin
admin.site.register(Entry)

Damit das Admin-Interface erreichbar ist, muss man einen Eintrag in der URL-Konfiguration vornehmen. Wie schon beschrieben, basiert die URL-Konfiguration auf regulären Ausdrücken, die auf Funktionen (oder andere ausführbare Python-Typen) gemappt werden. Um das Admin-Interface unter „/admin/“ erreichbar zu machen, genügt die folgende URL-Konfiguration:

from django.conf.urls.defaults import *
from django.contrib import admin
admin.autodiscover()

urlpatterns = patterns('', (r'^admin/(.*)', admin.site.root),)

Die Einträge sind übrigens schon vorhanden und müssen nur einkommentiert werden. Der Aufruf der „autodiscover“-Methode führt dazu, dass auch django.contrib-Applikationen im Admin-Interface registriert werden, ohne dass man dies von Hand tun muss.

Bevor es nun richtig los geht, müssen noch ein paar Einstellungen in der „settings.py“ vorgenommen werden. Django bringt von Haus aus Unterstützung für MySQL, PostgreSQL, Oracle und SQLite mit, für die lokale Entwicklung ist SQLite in den meisten Fällen vollkommen ausreichend. Deshalb reicht es, die folgenden beiden Einstellungen vorzunehmen:

DATABASE_ENGINE = 'sqlite3'
DATABASE_NAME = 'sqlite.db'

Außerdem muss noch die Konfiguration der „INSTALLED_APPS“ in der „settings.py“ angepasst werden, damit Django die Datenmodelle finden kann und weiß, welche Datenbanktabellen eingerichtet werden sollen:

INSTALLED_APPS = (
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.sites',
 't3n.blog', # die Blog Applikation
 'django.contrib.admin', # das Admin-Interface
)

Die Datei „settings.py“ ist übrigens ein ganz reguläres Python-Skript, alle Konfigurations-Variablen sind normale Python-Datentypen.

Als nächstes bereitet man die Datenbank durch das Ausführen von „python manage.py syncdb“ vor und kann dann mit „python manage.py runserver“ den Entwicklungsserver starten. Unter http://127.0.0.1:8000 ist nun das Django-Projekt per Web-Browser erreichbar. Beim ersten Ausführen des „syncdb“-Kommandos wird man interaktiv nach dem Account des Administrators gefragt und kann Benutzername und Passwort angeben, sonst kann man sich später nicht direkt in das Admin-Interface einloggen.

Schließlich werden noch Views und Templates erstellt, um die Blog-Einträge auch öffentlich zugänglich zu machen. Dafür ist jedoch zunächst die URL-Konfiguration notwendig: Direkt in der Root-URL-Konfiguration werden folgende URL-Pattern für Detail- und Listen-Ansicht hinzugefügt:

#urls.py
(r'^entry/(?P<object_id>[\d]+)/$', 
'django.views.generic.list_detail.object_detail',
{'queryset': Entry.objects.all(),
'template_name': 'blog/entry_detail.html'}
),
(r'^$', 
 'django.views.generic.list_detail.object_list',
 {'queryset': Entry.objects.all(),
 'template_name': 'blog/entry_list.html'}
),

Der reguläre Ausdruck im ersten Pattern sorgt dafür, dass alle Anfragen an URLs beginnend mit „/entry/“ gefolgt von einer Zahl an einen von Djangos generischen Views weiter geleitet werden – genauer gesagt an den „object_detail“-View. Der View wird in diesem Fall mit vier Parametern aufgerufen: dem Request-Object, einem Parameter „object_id“ (der den Wert aus der URL enthält) sowie dem Parameter „queryset“, der ein Set von „Entry“-Objekten (in diesem Fall alle) enthält und eigentlich eine Datenbank-Abfrage darstellt. Die eigentliche Abfrage an die Datenbank wird aber immer erst zum letztmöglichen Zeitpunkt ausgeführt (lazy). Der vierte Parameter ist „template_name“. Er enthält den Namen des Templates, das gerendert werden soll. Der hier angegebene Name stimmt zwar mit dem Default-Namen des „object_detail“-Views überein, der nach dem Muster „<app_label>/<model_name>_detail.html“ aufgebaut ist, aber so wird deutlich, wie leicht man den Namen anpassen kann.

Der „object_detail“-View wird jetzt aus dem Queryset das Object heraussuchen, das den Primary-Key mit dem Wert von „object_id“ hat und dieses Objekt an das Template übergeben. Ein einfaches Template für die Detail-Ansicht eines Blog-Eintrags könnte so aussehen:

{% extends "base.html" %}

{% block content %} 
<h1>{{ object.title }}</h1>
<p>{{ object.content }}</p>
<p>By {{ object.author.username }} 
 on {{ object.pub_date|date:"Y-m-d H:i" }}</p>
{% endblock %}

Dieses Template wird unter „t3n/blog/templates/blog/entry_detail.html“ oder in einem Ordner abgespeichert, der in der „settings.py“ unter „TEMPLATE_DIRS“ angegeben ist.

Das Template „blog/entry_detail.html“ erbt vom Template „base.html“ (noch nicht erstellt) und überschreibt den Block „content“. In diesem Block wird mit doppelten, geschweiften Klammern auf die Variable „object“ zugegriffen, die das Entry-Objekt beinhaltet, das der View aus der Datenbank geholt halt.

Der Ausdruck „{{ object.author.username }}“ folgt der ForeignKey-Relation zwischen „Entry“ und „User“ und greift auf das User-Objekt zu, das dem Entry zugeordnet ist. Von diesem wird dann das Attribut „username“ ausgegeben.

Ein weiteres Template-Feature sind die sogenannten Template-Filter, hier am Beispiel des Veröffentlichungsdatums zu sehen. „|date“ wendet den Date-Filter auf das Datums-Objekt an und formatiert es entsprechend des angegebenen Format-Strings „"Y-m-d H:i"“ (das Format entspricht übrigens dem der PHP-Funktion „date()“).

Das Basistemplate kann nun der Einfachheit halber unter „t3n/blog/templates/base.html“ abgelegt werden. Es würde (stark vereinfacht ) zum Beispiel so aussehen:

<html>
<head>
 <title>{% block pagetitle %}t3n django blog{% endblock %}</title>
 <!-- add css and js here -->
</head>
<body>
{% block content %}{% endblock %}
</body>
</html>

Am Seitentitel kann man hier sehr gut den Vererbungsmechanismus der Template-Engine erkennen. Das Basis-Template definiert den HTML-Titel als "t3n django blog". Überschreibt ein Template, das vom Basis-Template erbt, den Block „pagetitle“ nicht, so erscheint als Seitentitel "t3n django blog". Fügt man aber etwa im Template „blog/entry_detail.html“ noch folgende Zeile hinzu, wird auch der Seitentitel durch den Titel des Blog-Eintrags ersetzt.:

{% block pagetitle %}{{ object.title }}{% endblock %}

Über die Variable „{{ block.super }}“ kann man dann auch noch auf den Inhalt des übergeordneten Templates zugreifen. Ergänzt man die Zeile also wie folgt, wird an den Seitentitel immer noch der Titel der Seite angehängt:

{% block pagetitle %}{{ object.title }} - {{ block.super }}{% endblock %}

Mit diesem Mechanismus lassen sich übrigens auch sehr einfach Breadcrump-Navigationen zusammenbauen, da die Vererbung auch mehrstufig funktioniert. Der Vollständigkeit halber hier das Template für die Listen-Ansicht aller Blog-Einträge mit For-Schleife und URL-Block zur Rückwärtsauflösung von URLs, das beim Aufruf der Root-URL („/“) angezeigt wird:

{% extends "base.html" %} 

{% block content %}
<ul>
{% for object in object_list %}
<li><a href="{% url
django.views.generic.list_detail.object_detail object.id %}">{{
object.title }}</a></li>
{% endfor %}
</ul> 
{% endblock %}

Damit ist das kleine Beispiel für eine erste Django-Anwendung auch schon abgeschlossen. Im Prinzip war das nicht einmal die Spitze des Eisbergs, denn erst in etwas komplexeren Szenarien kann Django sein volles Potenzial ausspielen. Trotzdem sieht man, mit wie wenig Code sich erste Ergebnisse erzielen lassen.

Django bringt von Haus aus sehr gute Komponenten mit, die gut aufeinander abgestimmt sind. Trotzdem wurde überall auf lose Kopplung geachtet, so ist es etwa ohne größere Schwierigkeiten möglich, eine andere Template-Engine zu benutzen oder über einen anderen Datenbank-Abstraktions-Layer auf die Datenbank zuzugreifen. Django zwingt dem Entwickler hier keine Lösungen auf, sondern lässt ihm viel Freiheit und bietet jede Menge Ansatzpunkte, vorhande Mechanismen selbst zu erweitern, ohne am Framework selbst arbeiten zu müssen. Eigene Authentifizierung-, Session- oder Cache-Backends können problemlos selbst erstellt und in eigenen Projekten verwendet werden, ohne dass diese Teil von Django werden müssen.

Der Autor

Arne Brodowski ist selbständiger Software-Entwickler und beschäftigt sich seit fast zehn Jahren mit dem Erstellen von Websites und Webanwendungen. Wenn Arne nicht grade Web-Anwendungen in Python oder PHP programmiert, trainiert er mit dem Rennrad für die Vattenfall Cyclassics. Er bloggt unter http://www.arnebrodowski.de/blog/