Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
1 Einleitung
2 Überblick über Python
3 Die Arbeit mit Python
4 Der interaktive Modus
5 Grundlegendes zu Python-Programmen
6 Kontrollstrukturen
7 Das Laufzeitmodell
8 Basisdatentypen
9 Benutzerinteraktion und Dateizugriff
10 Funktionen
11 Modularisierung
12 Objektorientierung
13 Weitere Spracheigenschaften
14 Mathematik
15 Strings
16 Datum und Zeit
17 Schnittstelle zum Betriebssystem
18 Parallele Programmierung
19 Datenspeicherung
20 Netzwerkkommunikation
21 Debugging
22 Distribution von Python-Projekten
23 Optimierung
24 Grafische Benutzeroberflächen
25 Python als serverseitige Programmiersprache im WWW mit Django
26 Anbindung an andere Programmiersprachen
27 Insiderwissen
28 Zukunft von Python
A Anhang
Stichwort

Download:
- ZIP, ca. 4,8 MB
Buch bestellen
Ihre Meinung?

Spacer
 <<   zurück
Python von Peter Kaiser, Johannes Ernesti
Das umfassende Handbuch - Aktuell zu Python 2.5
Buch: Python

Python
gebunden, mit CD
819 S., 39,90 Euro
Galileo Computing
ISBN 978-3-8362-1110-9
Pfeil 25 Python als serverseitige Programmiersprache im WWW mit Django
  Pfeil 25.1 Installation
  Pfeil 25.2 Konzepte und Besonderheiten im Überblick
  Pfeil 25.3 Erstellen eines neuen Django-Projekts
  Pfeil 25.4 Erstellung der Applikation
  Pfeil 25.5 Djangos Administrationsoberfläche
  Pfeil 25.6 Unser Projekt wird öffentlich
  Pfeil 25.7 Djangos Template-System
  Pfeil 25.8 Verarbeitung von Formulardaten


Galileo Computing - Zum Seitenanfang

25.6 Unser Projekt wird öffentlich  topZur vorigen Überschrift

Bis hierher ist unser Projekt so weit gediehen, dass eine Datenbank mit News-Meldungen und Kommentaren erstellt worden ist. Außerdem können wir die Daten über ein bequemes Webinterface verwalten.

In diesem Kapitel werden wir uns mit dem »Gesicht« unserer Seite beschäftigen, also dem, was der Besucher der Website zu sehen bekommen soll.

Sie erinnern sich sicherlich noch an das Schema zum Aufbau der Model-View-Architektur im Kapitel zur Einführung von Django.

Bildlich gesprochen haben wir uns in Abbildung 25.10 von links nach rechts genau bis zur Mitte vorangearbeitet, da wir uns bereits mit Modellen und Datenbanken, nicht aber mit den Views und der Benutzerschnittstelle beschäftigt haben. Wir werden uns nun um die rechte Seite des Schemas kümmern.

Abbildung 25.10  Den linken Teil kennen wir nun

Views

Eine View ist eine einfache Python-Funktion, die das zurückgibt, was im Browser des Besuchers angezeigt werden soll. Welche Art von Daten das genau ist, kann frei gewählt werden. Eine View kann beispielsweise HTML-Quelltext zurückgeben, aber auch einfacher Text oder sogar Binärdateien wie Bilder sind durchaus denkbar. In der Regel werden Sie für alles eine eigene View definieren, was Sie auf einer Website anzeigen wollen.

Unser Beispielprojekt wird zwei Views haben: eine zum Anzeigen einer Meldungsübersicht und eine für die Ansicht einer einzelnen Meldung inklusive ihrer Kommentare. Die View-Funktion für die Meldungsübersicht bekommt von uns den Namen meldungen, und die andere nennen wir meldungen_detail.

Da wir uns in diesem Abschnitt auf den prinzipiellen Umgang mit Views konzentrieren möchten, werden wir eine normale Text-Ausgabe verwenden. Wie Sie auch komfortabel HTML-Quellcode erzeugen können, zeigen wir dann im nächsten Abschnitt.

Die Views einer Applikation werden üblicherweise in der Datei views.py abgelegt. Eine views.py, die eine View-Funktion meldungen für die einfache Textausgabe unserer Meldungen enthält, kann folgendermaßen aussehen:

from unser_projekt.news.models import Meldung, Kommentar 
from django.http import HttpResponse 
 
def meldungen(request): 
    zeilen = [] 
    for m in Meldung.objects.all(): 
        zeilen.append("Titel: '%s' vom %s" % (m.titel, 
                                              m.zeitstempel)) 
        zeilen.append("Text: %s" % m.text) 
        zeilen.append("") 
        zeilen.append("-" * 30) 
        zeilen.append("") 
 
    antwort = HttpResponse("\n".join(zeilen)) 
    antwort["Content-Type"] = "text/plain" 
    return antwort

Am Anfang binden wir per import unsere beiden Model-Klassen aus der news-Applikation des Projekts ein. Anschließend importieren wir eine Klasse namens HttpResponse aus dem Modul django.http, die wir in unseren Views benutzen, um das Ergebnis zurückzugeben.

Die View-Funktion meldungen bekommt von Django einen Parameter namens request übergeben, mit dem wir auf bestimmte Informationen der Abfrage zugreifen können. Wir werden request erst im nächsten Kapitel brauchen.

Innerhalb von meldungen verwalten wir eine Liste namens zeilen, die alle Textzeilen des Ergebnisses speichert. In einer for-Schleife iterieren wir über alle Meldungen in der Datenbank, die wir mit der Model-API auslesen, und fügen jeweils fünf Zeilen für jede Meldung in die Liste zeilen ein.

Am Ende erstellen wir eine Instanz des Datentyps HttpResponse, dessen Konstruktor wir die Verkettung der Zeilen als Parameter übergeben. Wichtig ist, dass wir über den []-Operator den "Content-Type" (dt. Inhaltstyp) der Ausgabe mit "text/plain" auf einfachen Text setzen, weil es sonst im Browser zu Darstellungsproblemen kommt. [Mit dem []-Operator von HttpResponse-Instanzen können beliebige HTTP-Kopfdaten gesetzt werden. ]

Bevor wir uns das Ergebnis unserer Bemühungen im Browser ansehen können, müssen wir Django mitteilen, unter welcher Adresse die View zu erreichen sein soll.

Adressen definieren

Wenn Sie schon selbst Webseiten erstellt haben, sind Sie es wahrscheinlich gewohnt, dass Sie Ihre Scripts (beispielsweise index.php) und andere Dateien (wie beispielsweise Bilddateien) direkt über deren Adresse auf dem Server ansprechen können. Liegt beispielsweise eine Datei index.php im Verzeichnis meine_seite/scripts/ relativ zum Wurzelverzeichnis des Webservers unter der Adresse http://www.server.de, können Sie es über die Adresse http://www.server.de/meine_seite/scripts/index.php ansprechen.

Django geht einen anderen Weg, indem es vollständig von der Ordnerstruktur des Servers abstrahiert: Anstatt die Adressen der realen Dateien auf dem Server für den öffentlichen Zugang zu übernehmen, können Sie selbst angeben, über welche Adresse ein bestimmter Teil der Seite erreichbar sein soll. Dabei ist jede View einzeln ansprechbar und kann mit einer beliebigen Adresse verknüpft werden.

Die Konfiguration der Adressen erfolgt über Regular Expressions [Details zu Regular Expressions (dt. regulären Ausdrücken) können Sie in Abschnitt 15.2 nachlesen. ] in der Datei urls.py des Projekts. In der Datei urls.py wird eine Variable namens urlpatterns definiert, die in einer patterns-Instanz eine Liste mit allen Adressen des Projekts enthält. Die Adressangaben selbst sind Tupel mit zwei Elementen, wobei das erste Element den regulären Ausdruck für die Adresse und das zweite Element den Importnamen der verknüpften View enthält. Eine typische urls.py, die auch schon eine Adressangabe für unsere meldungen-View enthält, sieht wie folgt aus:

from django.conf.urls.defaults import * 
 
urlpatterns = patterns('', 
    (r'^meldungen/$', 'unser_projekt.news.views.meldungen'), 
 
    # Uncomment this for admin: 
    (r'^admin/', include('django.contrib.admin.urls')), 
)

Der reguläre Ausdruck r'^meldungen/$' passt genau auf den String "meldungen". Wird nun eine Seite unseres Projekts aufgerufen, prüft Django der Reihe nach für alle Einträge der urlpatterns-Liste, ob der reguläre Ausdruck auf den relativen Pfad der geforderten Adresse passt. Ist dies der Fall, wird die Funktion aufgerufen, die durch den String im zweiten Element des Tupels beschrieben wird. Läge unsere Anwendung auf einem Server mit der Adresse http://www.meinserver.de, würde mit http://www.meinserver.de/meldungen/ die View meldungen aufgerufen.

Ergänzen Sie die urls.py um die Zeile (r'^meldungen/$', 'unser_projekt. news.views.meldungen'), und rufen Sie dann die entsprechende Adresse http://127.0.0.1:8000/meldungen/ in Ihrem Browser auf. Das Ergebnis sollte so aussehen wie in Abbildung 25.11.

Abbildung 25.11  Unsere erste eigene Django-Seite im Browser

Nun wollen wir auch eine Adresse und eine View für die Detailseite der Meldungen definieren.

Parametrisierte Adressen

Wir wollen nun auch die Detailseite jeder Meldung für den Benutzer zugänglich machen. Dabei wäre es äußerst unschön, für jede Meldung eine eigene View-Funktion zu definieren, da wir einerseits den Programmcode mit redundantem Code aufblähen und andererseits die Anzahl möglicher Meldungen dadurch begrenzen würden, wie viele View-Funktionen wir implementieren.

Wesentlich eleganter ist es, wenn wir eine View-Funktion definieren, die jede beliebige Meldung darstellen kann. Welche Meldung konkret angefordert wird, soll dabei über einen Parameter festgelegt werden, der die id der gewünschten Meldung enthält.

Django unterstützt die Parameterübergabe für Views über sogenannte benannte Gruppen, die wir im Abschnitt über reguläre Ausdrücke (Abschnitt 15.2.1) behandeln. Mit benannten Gruppen können wir Teile aus einem String extrahieren und ihnen Namen geben, wenn ein bestimmter regulärer Ausdruck auf den String passt.

Um die einzelnen Meldungen über Adressen wie http://www.server.de/meldungen/1/ und http://www.server.de/meldungen/2/ erreichbar zu machen, ergänzen wir in der urls.py folgende Zeile:

(r'^meldungen/(?P<meldungs_id>\d+)/$', 'unser_projekt.news.views.meldung_detail'),

Wenn nun ein Besucher der Seite auf die Adresse http://www.server.de/meldungen/1/ zugreift, versucht Django, die Funktion unser_projekt.news. views.meldung_detail aufzurufen. Dabei wird zusätzlich zu dem request-Parameter ein Schlüsselwortparameter meldungs_id mit dem Wert 1 übergeben.

Damit können wir einen ersten View-Prototyp meldung_detail in die Datei views.py schreiben:

from django.http import HttpResponse, Http404 
from unser_projekt.news.models import Meldung 
 
def meldungen(request): 
    ... 
 
def meldung_detail(request, meldungs_id): 
    try: 
        m = Meldung.objects.get(id=meldungs_id) 
    except Meldung.DoesNotExist: 
        raise Http404 
 
    zeilen = [ 
        "Titel: '%s' vom %s" % (m.titel, m.zeitstempel), 
        "Text: %s\n" % m.text, 
        "-" * 30 + "", 
        "Kommentare:", 
        ""] 
 
    zeilen += ["%s: %s" % (k.autor, k.text) 
               for k in m.kommentar_set.all()] 
 
    antwort = HttpResponse("\n".join(zeilen)) 
    antwort["Content-Type"] = "text/plain" 
    return antwort

Wir importieren zusätzlich die Exception Http404, um einen Fehler an den Browser des Besuchers zu senden, falls er eine nicht vorhandene Meldung aufruft. Als Wert für den Parameter meldungs_id bekommen wir bei jedem Aufruf der View den Wert übergeben, der in der Adresse angegeben wurde. In einer try/except-Anweisung versuchen wir, die passende Meldung auszugeben, und erzeugen bei Misserfolg den oben genannten Http404-Fehler.

Konnte die Meldung erfolgreich aus der Datenbank gelesen werden, speichern wir die Text-Zeilen für die Benutzerseite in der Liste zeilen und erzeugen außerdem mittels einer List Comprehension Ausgaben für alle Kommentare der Meldung.

Schlussendlich packen wir das Ganze auf gewohnte Weise in eine HttpResponse-Instanz, die wir per return zurückgeben.

Die von meldung_detail erzeugte Ausgabe sieht nun beispielsweise so aus wie in Abbildung 25.12.

Abbildung 25.12  Beispiel einer Meldungsdetailseite

Shortcut-Funktionen

Wenn Sie Webanwendungen entwickeln, werden sich in Ihrem Code sehr oft ähnliche Strukturen wiederfinden. Beispielsweise ist es sehr gängig, einen Datensatz aus der Datenbank abzurufen und, wenn dieser nicht existiert, einen Http404-Fehler zu erzeugen.

Damit Sie nicht jedes Mal den kompletten Code eintippen müssen und dadurch Ihren Programmtext künstlich aufblasen, bietet Django sogenannte Shortcut-Funktionen an, die häufig benötigte Aufgaben für Sie übernehmen. Alle Shortcut-Funktionen befinden sich im Modul django.shortcuts und können bequem per import eingebunden werden.

Um beispielsweise einen Datensatz aus der Datenbank abzufragen und bei Misserfolg eine Http404-Exception zu werfen, dient die Shortcut-Funktion get_object_or_404. Die Funktion get_object_or_404 hat fast die gleiche Schnittstelle wie die get-Methode der Model-API, mit der einzigen Ausnahme, dass als erster Parameter die Model-Klasse des gesuchten Datensatzes übergeben werden muss.

Damit wird aus der umständlichen try/except-Anweisung eine schlanke Zuweisung (vergessen Sie nicht, get_object_or_404 aus django.shortcuts zu importieren):

m = get_object_or_404(Meldung, id=meldungs_id)

Django definiert eine Reihe weiterer Shortcut-Funktionen, die wir hier nicht thematisieren werden. In der Dokumentation zu Django findet sich eine ausführliche Beschreibung aller verfügbaren Shortcuts.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.






 <<   zurück
  
  Zum Katalog
Zum Katalog: Python






Python
bestellen
 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchtipps
Zum Katalog: Linux






 Linux


Zum Katalog: Ubuntu GNU/Linux






 Ubuntu GNU/Linux


Zum Katalog: Praxisbuch Web 2.0






 Praxisbuch Web 2.0


Zum Katalog: UML 2.0






 UML 2.0


Zum Katalog: Praxisbuch Objektorientierung






 Praxisbuch Objektorientierung


Zum Katalog: Einstieg in SQL






 Einstieg in SQL


Zum Katalog: IT-Handbuch für Fachinformatiker






 IT-Handbuch für Fachinformatiker


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo





Copyright © Galileo Press 2008
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de