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:
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://127.0.0.1:8000/
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:
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.
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
Comments
Sehr schön, darf ich das Tutorial auf der Django Seite eintragen oder machst du das ? Dann ist es einem weiteren Kreis auch nützlich...
Ich hoffe du benutzt im nächsten Teil 'newforms'?! Da die 1.0 etwa im April raus sein soll und die API dann lange so bleibt...
http://www.djangoproject.com/documentation/newforms/
Weiss gar nicht, wo man das eintragen kann!? Gibts da ne Ecke mit nicht-englischen Tutorials? 'newforms' kenne ich noch gar nicht so richtig, muss ich mir wohl mal anschauen. Hatte eigentlich vor, erstmal vorzustellen, was ich so in mein Blog eingebaut habe, und wie das geht :)!
Unter 'Tutorials on the Web':
http://code.djangoproject.com/wiki/DjangoResources
Und da kannste deine Seite eintragen:
http://code.djangoproject.com/wiki/DjangoPoweredSites
Die steht da schon :)!
hi, ich finde Django auch sehr sehr spannend. Und möchte demnächst mal ein Projekt damit umsetzen, nur stellt sich mir die Frage, auf welchen Webspace ich mein django Projekt laufen lassen kann. Die gängigen Anbieter haben sowieso nur PHP, Perl Unterstützung und bei einigen wenigen findet man seit neustem Ruby Unterstützung, aber Python ist mir noch nicht untergekommen und einen eigenen gekauften/gemieteten Server will ich mir nicht leisten wollen.
Hey! Also Django ist ne coole Sache. Ich habe das damals auch einfach nur dringend ausprobieren wollen. Habe meine komplette Seite lokal programmiert und mir eigentlich erstmal noch keine wirklichen Gedanken ums Hosting gemacht.
Letztendlich läuft die Seite jetzt auf einem Vserver bei Strato, und ich muss sagen, ich bin mehr als zufrieden. Super Performance und nen saubere Konfiguration. Im Vergleich zu z.B. Server4You kann ich nur sagen top!
Guck Dich vielleicht einfach mal um, so viel teurer sind die Vserver gar nicht, als nen Webspace Paket, und man hat echt viel mehr Möglichkeiten.
Ich hab momentan 'nen kleinen Server bei Netdirekt (ca.20 Euro) mit monatlicher Kündigungsmöglichkeit...
Ansonsten kannst du bei OVH fragen, wie da die Pythonunterstützung aussieht.
Ein Beispiel: http://www.ovh.de/produkte/90plan.xml
Ich werde da in Zukunft wohl auch was (Server) mieten..., hätte ich grade nicht was anderes zu tun hätte, hätte ich vielleicht auch sowas wie Django/Rails etc. Hosting angeboten...
Das coolste was es da momentan gibt: http://www.webfaction.com/shared_hosting
Nur leider in den USA und für Seiten mit vorwiegend europäischem Publikum nicht wirklich tauglich.
Control Panel Demo: http://blog.webfaction.com/?page=5
"Windows-User sollten vermutlich XAMPP verwenden, und die LINUX-Benutzer sind solche Cracks, dass sie selber wissen, was sie brauchen ;)!"
Da inzwischen auch viele unbedarfte User Linux verwenden, da es inzwischen genauso einfach zu bedienen ist, wie (Windows) / OS X, könnte man darauf hinweisen, das auch für Linux XAMPP verfügbar ist - dies ist praktisch, um auch einfach nur mit "runterladen - entpacken - los gehts" eine komplette Serverumgebung auf dem Desktoprechner zu haben, die einfach gestartet und wieder gestoppt werden kann.
Für alle anderen empfiehlt sich, auf dem Heimrechner mit dem eingebauten Server von Django zu arbeiten, und auf der Datenbankseite mit SQLite - welches du in deiner Aufzählung vergessen hast.
Natürlich ist dieses nicht so performant wie mySQL oder PostgreSQL, aber für die Entwicklung der Seite und selbst für kleine Internetseiten, reicht dies vollkommen. Auch für kleine virtuelle Server, auf denen jedes Byte RAM zählt, bietet sich die Nutzung anstelle mySQL an.
Kannst du ja vll. einfließen lassen.
Grüße
Markus
Hallo Tim,
bin gerade zufaellig auf deinen interessanten Blog gestossen.
Ich bin gerade auf der Suche nach einem Provider fuer Django.
Du schriebst weiter oben, dass du mit dem V-Server von Strato zufrieden bist.
Ich nehme, an Python war da nicht defaultmaessig an und du hast die Seite selbst konfiguriert? Wenn ja, wie genau? Mit mod-python? Wie sieht es da mit Support aus?
Vielleicht kannst du mir ja einen Tip geben. Danke!
Gruss Dennis
Ähm, also soweit ich mich erinnern kann, war im Gegenteil schon fasst alles, was man für Django braucht auf dem Vserver default-mäßig an und installiert. Soll heißen ich konnte einfach die Django-Distribution runterladen und mit setup.py installieren.
Selbst mod_python war glaube schon an. Ansonsten war es aber definitiv nicht mehr, als das einkommentieren der entsprechenden Zeile in der httpd.conf! Django konfigurieren tut man dann mit nem entsprechenden Virtual-Host. Ist aber auch kein Problem. Entweder Du machst das anhand der Doku, die es bei Django online gibt oder sag Bescheid, dann kann ich Dir meine Virtual-Host Konfiguration mailen. Kein Problem also :)!
Erst einmal danke für deinen Blog Eintrag, leider gibt es davon viel zu wenig.
Habe mir gestern gedacht....installierste mal nen Forum, und reg. eine Domain. Wenn ihr also Lust habt, lasst uns eine kleine deutsche community starten, zumindest nen kleines Forum.
-> http://django-resource.de/
Bin selbst noch Django Neuling ;-)
Sascha