Tim Adler

Nachdem es ja in den letzten paar Beitragen quasi noch um vorbereitende Dinge für die letztendliche Umsetzung eines Blogs mit Django ging, solls es jetzt endlich losgehen mit der tatsächlichen Umsetzung in dieses gottgegebene (wertungsfrei!) Framework. 

Grundsätzlich ist Django sehr genügsam. Einzig wirkliche Systemvoraussetzung ist ein installiertes Python ab Version 2.3 und eine Datenbank (entweder MySQL oder Postgres).  Beides gibt es in beliebiger Variante für beliebige Betriebssysteme. Die Mac-User seien aber darauf hingewiesen, dass es wohl am besten ist, wenn man ein Original-Python und nicht das in Tiger integrierte verwendet.

Ich habe mich deshalb entschieden in meiner lokalen Installation zum einen mit MacPython eine möglichst aktuelle Python-Version zu installieren (Python in seiner normalen Version zu installieren ist mehr als nervig) und zum anderen MAMP zu verwenden, um mir die MySQL-Installation zu sparen. Beides arbeitet hervorragend zusammen.

Windows-User sollten vermutlich XAMPP verwenden, und die LINUX-Benutzer sind solche Cracks, dass sie selber wissen, was sie brauchen ;)!

Installation

Da Django zu fast allen Aufgaben ein sinnvolles Skript mitliefert, dass alle wichtigen Aufgaben übernimmt, ist die Installation denkbar einfach. Man lädt sich einfach von der Django-Homepage die aktuelle Version als TAR-Datei herunter und entpackt diese.

Danach wechselt man in das so entpackte Verzeichnis und wirft einen erstaunten Blick, auf all die schönen Dateien, die sich dort aufgetan haben. Darunter findet sich auch eine Datei setup.py, die sich mit folgenden Befehl zum Arbeiten bewegen lässt:

sudo python setup.py install
 

Der Django-Installer legt die Django-Files entsprechend der aktuellen Python-Einstellungen in das site-package Verzeichnis, auf das alle Python-Skript über den $PYTHON_PATH Zugriff haben.
Das heisst für den Benutzer aber auch: Django funktioniert anders, als beispielsweise ein PHP-Skript. Es werden keine speziellen Python-Dateien benötigt, um die einge Webseite zum Beispiel mit einem Kontroller für URLs zu versehen. Der Django-Testserver bzw. später ein Apache mit mod_python laden die benötigten Bibliotheken aus den Python-Bibliotheken und betreiben damit die Webseite. Deshalb sollte man vielleicht auch nicht mehr von Webseite reden, sondern lieber von Webapplikationen, denn es ist tatsächlich viel eher ein Programm.

Man kann relativ einfach testen, ob Django erfolgreich installiert ist, in den Python-Kommandozeileninterpreter mit "python" in der Konsole aufruft und folgedes eintippt:

import django
 

Damit importiert man die Django-Bibliothek in die Laufzeitumgebung, als ob man sie verwenden wollte. Es sollte keine Fehler geben. Wenn doch, vielleicht das Vorgehen nochmal anhand der offiziellen Dokumentation nachvollziehen.

Applikation aufsetzen

Nachdem man Django also fertig installiert hat, kann es auch schon direkt losgehen. Auch hier gibt es wieder ein komfortables Skript, mit dem sich die passenden Dateien automatisch anlegen lassen.
Man wechselt also am besten zuerst in ein Verzeichnis, in dem man das neue Django-Projekt, in diesem Fall das "Blog" ablegen möchte. ACHTUNG: Das ist sinnvollerweise nicht das DocumentRoot irgendeines Webservers. Wie gesagt, Django läuft quasi als Programm im Webserver und wird nicht direkt auf Dateien zugegriffen. Genaugenommen ist es sogar unsicher, sein Django-Projekt in ein DocumentRoot zu legen, weil sonst die Python-Dateien evtl. von außen zugreifbar werden.

Im passenden Verzeichnis angekommen, führt man nun wieder folgenden Befehl aus:

django-admin.py startproject blog
 

Dies legt ein neues Verzeichnis "blog" an, in dem später alles rund um die neue Django-Applikation geschehen wird. Folgende Dateien sind in dem Verzeichnis zu finden:

blog/
    __init__.py
    manage.py
    settings.py
    urls.py

• __init__.py Diese Datei ist eine Python-Konvention und bedeutet, dass das aktuelle Verzeichnis von Python als Package angesehen werden kann. Diese __init__.py-Dateien enthalten Initialisierungsskripte für ein Package. Eigentlich werden sie nicht weiter benötigt, müssen aber da sein. Wer mehr erfahren will, fragt am besten die offizielle Python-Dokumentation
• manage.py Diese Datei ist der beste Freund des Django-Programmierers. Sie enthält alle nötigen Skripte für Applikationserstellung und Testumgebung.
• setting.py Die zentrale Konfigurationsdatei für die neue Django-Applikation. Hier wird zum Beispiel die Datenbankkonfiguration konfiguriert.
• urls.py Hier werden die URLs konfiguriert, die später im Webserver verfügbar sein sollen. Dabei sind der Kreativität keine Grenzen gesetzt. Django arbeitet mit Regular Expressions, um die Anfragen auf bestimmte "Views" (Seiten, RSS-Feeds...) zu leiten.

Testumgebung

Jetzt ist bereits alles getan, um das erste Mal den Entwicklungsserver zu starten. Während man an seiner Django-Applikation arbeitet, braucht man keinen echten Apache, um seine Arbeit zu begutachten: Django liefert einen Python-basierten Miniwebserver mit, der direkt im Webapplikationsverzeichnis gestartet werden kann. Dieser hat u.a. den Vorteil, dass man ihn nach einer Änderung an .py-Dateien nicht ständig neu starten muss.

Man wechselt nun in das "blog"-Verzeichnis und startet den Testserver mit:

>> python manage.py runserver

Validating models...
0 errors found.
Django version 0.95, using settings 'mysite.settings'
Development server is running at http://www.tim-adler.com/
Quit the server with CONTROL-C (Unix) or CTRL-BREAK (Windows).

Wenn man nun die angegebene Adresse in seinem Webbrowser öffnet, sollte man eine Django-Willkommensseite sehen und weiss somit, dass es funktioniert hat. Es gibt die Möglichkeit den Server auch auf einer anderen IP/Port zu starten. Dazu gibt man einfach z.B. Folgendes ein: python manage.py runserver 192.168.0.1:8080.

Datenbank konfigurieren

Damit Django im Folgenden auch auf die Datenbank zugreifen kann, gibt man nun die entsprechenden Zugangsdaten in der settings.py an:

• DATABASE_ENGINE Der Typ der Datenbank, an die Django angebunden wird.
• DATABASE_NAME Die Datenbank innerhalb des DBMS, die man verwenden will.
• DATABASE_USER Username
• DATABASE_PASSWORD Passwort
• DATABASE_HOST Host
• DATABASE_PORT Port

Nachdem man diese Infos eingegeben hat, kann man auch diese Einstellung wieder testen. Folgendes in die Konsole eingeben:

python manage.py syncdb
 

Mit diesem Befehl synchronisiert man die bestehende Django-Konfiguration mit der Datenbank. D.h. alle benötigten Tabellen & Daten werden angelegt. Diesen Befehl verwendet man auch, um die eigenen Datenmodelle in die Datenbank zu bringen. Die bisherigen Tabellen stammen aus der Standardkonfiguration von Django, und verwalten zum Beispiel User und Sessions. In diesem Schritt wird man ebenfalls danach gefragt, ob Django einen Superuser für die Authentifikation anlegen soll. Ja, das sollte man :)!

Datenmodell erstellen

Jetzt kann man endlich mit der Erstellung des Datenmodells für sein Blog beginnen. Das ist eigentlich gar nicht weiter schwierig. Letztendlich erstellt man einfach nur Python-Klassen, die dann von Django in die Datenbank synchronisiert werden und auch verwaltet werden können.

Dazu bleibt allerdings noch eine Kleinigkeit zu tun, denn Django unterteilt das Projekt, welches man mit "blog" erstellt hat, noch in feinere Applikationen. Mit diesen hat man die Möglichkeit, die erstellte Webapplikation zu weit zu zerteilen, dass man bestimmte Bereiche in anderen Projekten wiederverwenden kann.

Für sein Blog kann man sich also verschiedene Teile überlegen, die man einbauen möchte. Grundsätzlich soll es aber bestimmt einen Bereich mit Beiträgen und Kommentaren geben, und dieser soll nun zu Beginn erstellt werden. Es gibt also wieder was einzugeben:

python manage.py startapp posts
 

Damit hat man eine neue Applikation erstellt, in der man nun alle Dinge programmieren und konfigurieren kann, die das Blog im Bereich Beiträgen und Kommentaren betreffen.

Django hat nun unter "blog" ein neues Verzeichnis "posts" erstellt, welches jetzt folgende Dateien enthalten sollte:

posts/
    __init__.py
    models.py
    views.py

• __init__py Ja, das ist wieder diese komische Package-markier-Datei. Vielleicht versteht jetzt schon jemand, warum ich das in Python mit den Packages nicht wirklich gut gelöst finde.
• models.py In dieser Datei pflegt man das gesamte Datenmodell, d.h. hier werden die Python-Klassen definiert, die später ein Equivalent in der Datenbank haben werden. Jede Python-Klasse entspricht später einer Tabelle in der Datenbank.
• views.py Hier werden, die Funktionen definiert, die die Behandlung von Anfragen an die Webseite übernehmen. Diese werden mit der urls.py entsprechend mit bestimmten URLs verbunden. Dazu aber später mehr.

Da Django später nur für solche Applikationen Tabellen anlegen wird, die auch unter den INSTALLED_APPS sind, kann man direkt jetzt noch einmal die settings.py öffnen und bis ans Ende scrollen. Hier findet sich genau eine solche Variable, in der auch schon einige Applikationen eingetragen sind. Diese Applikationen sind die Standard-Applikationen, für die Django weiter oben auch bereits schon Tabellen erstellt hat. Hier fügt man nun einen Eintrag für die gerade erstellte Applikation hinzu:

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'blog.posts'
) 

Jetzt ist die neue Applikation installiert und wird von Django bei allen Schritten mit berücksichtigt. Fehlt nur noch die Definition der Klassen, die später Beiträge und Kommentare abbilden sollen. Dazu öffnet man nun die models.py in der "posts" Applikation und fügt die folgenden epischen Zeilen hinzu:

from django.db import models
class Post(models.Model):
	title = models.CharField("Titel",maxlength=200)
	content = models.TextField("Inhalt")
	url_string = models.SlugField("URL",prepopulate_from=("title",))
	pub_date = models.DateTimeField('Datum','date published')
	
	def __str__(self):
		return "%s" % (self.title)

	class Meta:
		ordering = ['-pub_date']
		verbose_name = "Blog-Eintrag"
		verbose_name_plural = "Blog-Einträge"

class Comment(models.Model):
	name = models.CharField("Name",maxlength=200)
	email = models.CharField("Email-Adresse",maxlength=200)
	url = models.CharField("Homepage",maxlength=200,blank=True)
	text = models.TextField("Kommentar")
	pub_date = models.DateTimeField("Datum",'date published')
	post = models.ForeignKey(Post,related_name='comments')

	class Meta:
		ordering = ['-pub_date']
		verbose_name = "Kommentar"
		verbose_name_plural = "Kommentare"

Hier werden also zwei neue Python-Klassen definiert, die beide von der Klasse "models.Model" erben. Diese Oberklasse stammt natürlich aus der Reihe der Django-Klassen. Danach werden in jeder Klasse einige passende Attribute definiert. Dabei verwendet man zur Bestimmung des Typs eine Definition aus den verfügbaren Django-Models. Das Ganze ist relativ selbsterklärend, und die verschiedenen verfügbaren Typen sind in der Model Reference super erklärt. Deshalb jetzt nur etwas zu den Besonderheiten:

• Feldnamen im Klartext
  Alle Attribute der Klasse, definiert man in der Initialisierung mit einem String zur Klartextbenennung. Django verwendet diesen Namen, um ihn im Backend für das jeweilige Eingabefeld zu verwenden.
• __str__ Methode
  Diese Methode ist wichtig, um sinnvolle Text für die Objekte in der Datenbank zu haben. Im Admininterface zeigt Django diesen Text an, um ein Objekt zum Beispiel in Listen darzustellen.
• url_string - SlugField
  Diese Feld ist eine Vorbereitung auf lesbare URL für das Blog. In Django ist es möglich die URLs frei zu definieren, deshalb verzichtet man für das Blog auch auf jeden Ansatz für irgendwelche Parameter oder Zahlen in den URLs. Dieses Feld ist ausschließlich dafür da, die URL für einen bestimmten Post individuell zu konfigurieren.
  SlugField haben die super Eigenschaft, auf bestimmte Dinge bereits zu achten: So wird es durch die prepopulate-Eigenschaft direkt mit dem Wert bestückt, den man unter "titel" angibt, außerdem kann es keine Umlaute oder nicht-urlfähigen Zeichen enthalten.
• Meta-Klasse
  Django verwendet zusätzliche innere Klassen, um Textangaben für das Backend einstellen zu können. In der inneren Klasse "Meta" kann man die Standardsortierung und die Klartextnamen einstellen.
• ForeignKey in den Kommentaren
  Das Prinzip ist ja denkbar einfach: Zu jedem Beitrag soll es beliebig viele Kommentare geben können. Diese 1:n Beziehung bildet man in Django auch genau so ab. D.h. man gibt für einen Kommentar einen übergeordneten Beitrag, über den sich Kommentare zu Beiträgen zuordnen lassen.
• blank-Felder
  Beide Eigenschaften legen bestimmte Bedigungen fest: Ist ein Feld auf "blank=True" gesetzt, so darf dieser Wert für ein bestimmtes Objekt auch leer sein. D.h. es darf in der Datenbank NULL stehen, auch wenn das Objekt gespeichert wird.

Jetzt kann man das Datenmodell mit dem bekannten Befehl in die Datenbank übertragen lassen.

python manage.py syncdb
 

Automatisches Adminbackend

Damit in diesem Teil des Tutorials nicht alles ausschließlich theoretisch bleibt, guckt man sich im letzten Schritt das gerade Konfigurierte schonmal im Administrationsbackend an. Wie bereits angedeutet, brauch man sich draum überhaupt nicht zu kümmern, was ich für einen der größten Vorteile von Django gegenüber Ruby on Rails oder CakePHP halte. Im Übrigen lässt sich der gesamte Django-Adminbereich ebenfalls vollständig Templaten und mit eigenen CSS versehen. Sollte einem das Backend optisch also nicht zusagen, kann man es dem eigenen Geschmack problemlos anpassen.

Für das Aktivieren das Admin-Backends gibt es dabei nicht mal viel zu tun:

• Man fügt django.contrib.admin in der settings.py zu den INSTALLED_APPS hinzu.
• Jetzt führt man wieder python manage.py syncdb aus, da es evtl. Änderungen an den bestehenden Tabellen geben könnte.
• Im letzten Schritt konfiguriert man in der urls.py im "blog"-Verzeichnis die Zeilen für das Admin-Interface wieder ein.

Startet man nun den Testserver sollte man unter http://<angezeigte Adresse>/admin das Admininterface kriegen. Die Userdaten sind die des, weiter oben konfigurierten Superusers. In diesem Backend kann man jetzt schonmal etwas herumspielen.

Im nächsten Teil werden wir uns dann angucken, wie man die Beiträge anzeigt, Klartext-URLs konfiguriert und Kommentare akzeptiert. Evtl. nehmen wir auch gleich noch die Integration von Gravataren, Feeds und Akismet mit ins Boot.

Vorher: Blog mit Django: Design & Konzept
Vorher: Blog mit Django: XHTML/CSS
Vorher: CSS-Coding-Tipps
Nachher: Blog-Features für Django