Django - Agiles Web-Entwicklungsframework für Python

Inhaltsverzeichnis

Abbildungsverzeichnis

Listingsverzeichnis

Abkurzungsverzeichnis

1 Einleitung
1.1 Geschichte der Webentwicklung
1.2 Ziel der Arbeit

2 Werkzeuge und Methoden moderner Webentwicklung
2.1 MVC-Architektur
2.1.1 Komponenten
2.1.2 Beziehungen zwischen den Komponenten
2.2 Frameworks - Instrumente der modernen Webentwicklung
2.3 DRY - Don’t repeat yourself

3 Django - ein Python Web Framework
3.1 Python - eine dynamische objektorientierte Programmiersprache
3.2 MVC-Architektur in Django
3.3 Die Verwendung von Django
3.3.1 Installation
3.3.2 Django-Grundlagen
3.3.3 Django und Datenbanken: vom Modell zum Datenbankschema
3.3.4 Django-Template-System und Django-Views
3.3.5 Django und Apache: mod_python
3.3.6 Django - Admininterface

4 Fazit

Literaturverzeichnis

Abbildungsverzeichnis

2.1 MVC Architektur [vgl. Sun Mircosystems (2002)]

3.1 Django - Ablauf - Request / Reponse [vgl. Holovaty A., Kaplan-Moss J. (2008), Seite 22]

Listingsverzeichnis

3.1 Beispielcode Python

3.2 Python - Interaktiver Interpreter

3.3 Django - Ordnerstruktur

3.4 Django - Subversion Checkout

3.5 Django - Verlinkung in Python site-packages

3.6 Django - django-admin.py

3.7 Django-Projekt erstellen

3.8 Django - Projektstruktur

3.9 Django - Developmentserver starten

3.10 Django - Anwendung erstellen

3.11 Django - Anwendungsstruktur

3.12 Django - Datenbankeinstellungen

3.13 Django - Beispielanwendung - models.py

3.14 Django - Beispielanwendung - settings.py

3.15 Django - Beispielanwendung - Modellvalidierung

3.16 Django - Beispielanwendung - Synkronisation

3.17 Django - Beispielanwendung - Template

3.18 Django - settings.py - Template Directory

3.19 Django - Beispielanwendung - views.py

3.20 Django - Beispielanwendung - urls.py

3.21 Django - Apache2 Konfiguration

3.22 Django - Aktivierung Administrationsinterface

3.23 Django - Administrationsinterface - urls.py

3.24 Django - Administrationsinterface - models.py

Abkurzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

1.1 Geschichte der Webentwicklung

Zu Beginn der Webentwicklung wurde jede Internetseite von Hand geschrieben bzw. pro- grammiert. Eine bestehende Webseite zu warten, d.h. aktuell zu halten, bedeutete direkt HTML¹ zu bearbeiten.

Mit der Zeit und den steigenden Anforderungen an Webseiten wurde es schnell of- fensichtlich, dass diese Situation so nicht tragbar war. Eine Gruppe ambitionierter Pro- grammierer der NSCA² schaffte es erstmals dynamisch HTML-Inhalte von einem externen Programm erstellen zu lassen, sie nannten dieses Protokoll CGI - Common Gateway In­terface.

CGI-Skripte haben aber ihre Probleme: Sie benotigen vielen, sich wiederholenden Code - die Wiederverwendung von Code-Fragmenten gestaltet sich schwierig und die Greifbar- keit und Verstandlichkeit des Codes ist gerade fiir Einsteiger nicht gewahrleistet.

PHP³ lost viele dieser Probleme. Eine der bedeutsamsten Neuerungen mit PHP war der einfache Einstieg - die relativ flache Lernkurve brachte schnelle Erfolge. Aber auch PHP zwingt den Programmierer zu immer wieder denselben Code - die Wiederverwendbarkeit ist erst mit der Objektorientierung bedingt gegeben und speziell im Bereich Sicherheit lasst PHP einige Wunsche offen.

Eben diese Probleme fuhrten zu den sogenannten ’’third gen” Web Development Fra­meworks, wie sie durch Ruby on Rails oder Django vertreten werden.⁴

1.2 Ziel der Arbeit

Ziel dieser Arbeit ist es, das Framework Django und dessen Funktionsweise einer brei- teren Entwicklerioffentlickeit niaher zu bringen. In diesem Zusammenhang soll auch auf Entwurfsmuster, insbesondere auf das Entwurfsmuster ,,MVC“⁵ und dessen Bedeutung fur die moderne Webentwicklung, eingegangen werden. Ebenso werden Methoden der modernen Webentwicklung aufgegriffen und erlautert.

2 Werkzeuge und Methoden moderner Webentwick­lung

2.1 MVC-Architektur

Entwurfsmuster (Design Patterns) sind ursprunglich ein Konzept aus der (Gebaude-) Ar- chitektur, das im Rahmen der Programmiersprache und -umgebung Smalltalk fur die Softwareentwicklung ubernommen wurde. Im Wesentlichen geht es um die ubersichtli- che Katalogisierung einmal gefundener Losungen fur die spatere Wiederverwendung. Bei Entwurfsmuster handelt es sich keinesfalls um fertig programmierte Komponenten oder Codeschnipsel. Wie der Name schon sagt, gehoren sie zur Phase des Entwurfs und nicht zur Implementierung von Software. Dennoch enthalt ein Muster neben vielen anderen Komponenten auch Codebeispiele.

In der Softwareentwicklung wurden die Entwurfsmuster durch die ’’Gang of Four” (GoF) Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides eingefuhrt.

Jedes Entwurfsmuster besteht aus vier wesentlichen Komponenten:⁶

- Mustername

Das Muster sollte eine moglichst griffige Bezeichnung erhalten, die moglichst genau auf seinen Verwendungszweck hindeutet.

- Problemabschnitt

Eine genaue Beschreibung der Situation, in der das Entwurfsmuster eingesetzt wer- den kann.

- Laosungsabschnitt

Die abstrakte Beschreibung eines Entwurfsmuster, welches das Problem lost.

- Konsequenzenabschnitt

Eine Beschreibung der Folgen und moglichen Nebeneffekte, die der Einsatz des Ent- wurfsmusters mit sich bringt.

2.1.1 Komponenten

Ein bekanntes Entwurfsmuster, das nicht im GoF-Katalog vorkommt, ist zum Beispiel das MVC-Pattern. Es handelt sich um eine praktische Vorgehensweise zur sauberen Trennung von Datenmodell, Programmlogik und Prasentation. Es wurde bereits in den 1970er- Jahren im Smalltalk-Umfeld entwickelt und beschreibt den Idealzustand von APIs fur grafische Benutzeroberflachen.

Die MVC-Archiketur teilt eine Anwendung in folgende Teile:

Model (Modell) Das Model beinhaltet das Fachkonzept. Es ist also fur die interne Datenverarbeitung zustandig. Es tragt die Verantwortung fur die:

- Daten

Beispiel: In einer Anwendung werden aus einer Datenbank Daten abgefragt.

- Geschaftsmodell

Beispiel: Bei einem neu angelegten Produkt wird der Bruttopreis aus dem Nettopreis berechnet.

View (Presentation) Die View ist fur die Darstellung der Daten zustandig. Die View greift dazu uber eine definierte Schnittstelle auf die Daten des Model zu. Als Zustandig- keiten der View kuonnen aufgefuuhrt werden:

- Anzeige von Daten (aus dem Model)
- Anzeigelogik

Beispiel: ,,Wenn diese Kennzahl so, dann zeige Schaltflache X an.“

- Benutzerinteraktion bereitstellen Schaltflachen, Textfelder etc.

Controller (Steuerung) Der Controller bietet dem Benutzer verschieden Manipu- lationsmoaglichkeiten, um den Zustand des Model zu veraandern. Eer ist somit die einzige Schnittstelle, um Daten zu manipulieren. Unter die Zustandigkeit des Controllers fallen:

- Verwaltung der Views;
- Steuerung der Anzeige von Views;
- Entgegennahme und Weitergabe von Benutzereingaben (insbesondere Datenmani- pulation).

2.1.2 Beziehungen zwischen den Komponenten

Balzert H. (1999) beschreibt die Beziehungen der Komponenten in der MVC-Architektur wie folgt: „Die MVC-Architektur realisiert folgende Ideen: Das Model-Objekt (Fachkon­zept) weifi nicht, wie seine Daten auf der Oberflache dargestellt werden. Es darf nicht di- rekt auf seine assoziierten View- und Controller-Objekte zugreifen und dort Daten andern. Es besitzt lediglich eine Liste aller von ihm abhangigen Objekte. Bei einer Aktualisierung mufi es alle seine abhangigen Objekte uber diese Anderung informieren. Wenn View und Controller-Objekte geandert oder ausgetauscht werden, ist das Model-Objekt nicht davon betroffen.“

View-Controller-Beziehung

Jede View hangt direkt von einem Controller ab und vise versa. Dies ergibt sich aus der engen Verzahnung von Input und Output bei einer Anwendung. Fur Web-Frameworks die

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.1: MVC Architektur [vgl. Sun Mircosystems (2002)]

auf der MVC-Architektur aufbauen, heifit das, dass der Controller die Verarbeitung des Models iibernimmt, die View sorgt fur die Darstellung.

Model-View-Beziehung

Die View hangt vom Model ab. Anderungen am Model miissen parallel an den Views vollzogen werden.

Model-Controller-Beziehung

Der Controller hangt vom Model ab. Anderungen am Model haben direkte Auswirkungen auf den Controller.

Das MVC-Entwurfsmuster bzw. die MVC-Architektur garantiert somit ein flexibles Programmdesign, das eine spatere Anderung und/oder Erweiterung und die Wiederver- wendbarkeit von Code unterstutzt.

2.2 Frameworks - Instrumente der modernen Webentwicklung

Bevor auf ein aktuelles Framework der Webentwicklung naher eingegangen wird, muss der Begriff „Framework“ abgegrenzt werden.

Lahres B., Rayman G. (2006) definieren „Framework“ wie folgt:

„Das Grundkonzept von Frameworks ist es, einen Rahmen fur eine Anwendung oder einen Anwendungsbereich zur Verfugung zu stellen. Damit legen Frameworks eine Art Schablo- ne fur diesen Bereich fest, die bei der Entwicklung einer konkreten Anwendung dann ausgepragt wird.

Die Entwicklung einer Anwendung auf Basis von Frameworks besteht darin, dass Klas- sen und Methoden umgesetzt werden, die aus dem bereits existierenden Framework her- aus aufgerufen werden. Damit liegt die Steuerung des Kontrollflusses komplett bei den Framework-Klassen. Das Frameworks zugrunde liegende Prinzip wird deshalb auch Um- kehrung des Kontrollflusses (Inversion of Control) oder Hollywood-Prinzip genannt.“

Bachle M., Kirchberg P. (April 2007) trennen Web-Frameworks in zwei Klassen:

- ,,In ereignisgesteuerten Web-Frameworks definiert der Programmierer fur spezielle Kompenenten vorab die Reaktion auf ein bestimmtes Ereignis, welche dann zur Laufzeit durch Benutzeraktion mit der Komponente ausgelost werden kann.“⁷
- Aktionsgesteuerte Web-Frameworks orientieren sich staarker an den technischen Be- sonderheiten des HTTP⁸ -Protokolls und definieren ihre Anwendungssteuerung ent- lang des webtypischen Request/Response-Zyklus. Konzeptionell lehnen sich diese Web-Frameworks stark an das Model-View-Controller-(MVC) Muster an. [...]“⁹

Das Model-View-Controller Muster und dessen Konzept wurde bereits in Kapitel 2.1 erlautert.

Inversion of Control

Konventionell entwickelte Anwendungen nutzen eine Reihe von (Klassen-)Bibliotheken (APIs¹⁰ ). Diese werden von der Anwendung, welche sie nutzt, aufgerufen. Die Bibliotheken sind dabei Hilfsmittel und uabernehmen niemals den Hauptkontrollfluss der Anwendung. Immer wenn die Anwendung Funktionalitaten der externen Klassenbibliothek benotigt, ruft sie diese uber festgelegte Schnittstellen auf. Die Anwendungsarchitektur - den proze- duralen Ablauf - muassen die Entwickler selbst konstruieren, sie wird mit den Klassenbi- bliotheken nicht mitgeliefert. Im Gegensatz zu konventionell entwickelten Anwendungen invertieren die Frameworks den Kontrollfluss einer Anwendung. Die Anwendung wird da- durch vom Framework gesteuert. Die Vorgehensweise ist als Call-Back-Prinzip bekannt. Zentrale Bestandteile einer Anwendung und Software-Architektur werden bereits im Fra­mework vorgegeben. Die anwendungsspezifischen Funktionalitaaten einer Software, die auf einem Framework aufsetzen, werden meistens als Erweiterungen dieses Frameworks im- plementiert und werden aus dem Framework heraus aufgerufen. Auf diese Weise wird der Hauptkontrollfluss einer Anwendung durch das Framework gesteuert.¹¹

Die folgenden Punkte sprechen fur den Einsatz eines Frameworks:

- An der Entwicklung sind mehrere Personen beteiligt.
- Die Personen haben unterschiedliche Rollen (Programmierer, Webdesigner, Redak- teur).
- Die Webanwendung soil auf Fremdsysteme zugreifen.
- Sicherheit und rollenspezifisches Verhalten ist gewunscht.
- Inhalte sollen fur verschiedene Medien aufbereitet .

2.3 DRY - Don’t repeat yourself

DRY¹² steht fur ein Programmierparadigma das die Frage nach der Vermeidung von Wie- derholungen in der Softwareentwicklung beantwortet.

Andy Hunt und Dave Thomas schreiben in ihrem 1999 erschienenen Buch ,,The Pragmatic Programmer“¹³:

’’Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”

Als Programmierer sammelt man Wissen, man organisiert, pflegt und nutzt dieses. Das zur Verfugung stehende Wissen ist aber nicht vor Veranderung geschiitzt. Ganz im Gegen- teil: Wissen verandert sich, sei dies durch neuere Technologien, geanderte Anforderungen, andere gewahlte Algorithmen, etc.

In Bezug auf Codefragmente bedeutet dies, dass haufig derselbe Code an unterschiedli- chen Stellen in einem System auftaucht. Diese Wiederholungen verursachen so lange keine Probleme, wie der Code nicht geandert werden muss. Die Frage dabei ist nicht, ob die Wiederholungen vergessen werden, sondern wann. Dies kann zu ungewolltem Programm- verhalten an verschiedenen Stellen fuahren.

Griinde fur Wiederholungen in der Softwareentwicklung:

- Erzwungene Wiederholung.

Man scheint keine Wahl zu haben. Umstande scheinen die Wiederholung zu erfor- dern.

- Unabsichtliche Wiederholung.

Aus Versehen.

- Wiederholung aus Ungeduld.

Faulheit. Wiederholen, weil es einfacher scheint.

- Wiederholungen durch mehrere Entwickler.

Verschiedene Entwickler wiederholen dieselbe Information.

DRY gilt als eines der wichtigsten ,,Werkzeuge“ der modernen Webentwicklung.¹⁴

3 Django - ein Python Web Framework

3.1 Python - eine dynamische objektorientierte Programmier- sprache

’’Python is a dynamic object-oriented programming language that can be used for many kinds of software development. It offers strong support for integration with other languages and tools, comes with extensive standard libraries, and can be learned in a few days. Many Python programmers report substantial productivity gains and feel the language encourages the development of higher quality, more maintainable code.” [Python Software Foundation (2008)]

Die Skriptsprache Python wurde um 1989 von Guido van Rossum in den Niederlanden am Centrum voor Wiskunde en Information (CWI) in Amsterdam entwickelt. Van Rossum ist ein Anhanger der britischen Komikergruppe Monty Python¹⁵, woher der Name der Programmiersprache stammt.¹⁶

Bei Python handelt es sich um eine Scriptsprache, da kein expliziter Ubersetzungsvor- gang durch einen Compiler notwendig ist.¹⁷

Zu den Vorteilen von Python zahlen [Python Software Foundation (2008)]:

- very clear, readable syntax
- strong introspection capabilities
- intuitive object orientation
- natural expression of procedural code
- full modularity, supporting hierarchical packages
- exception-based error handling
- very high level dynamic data types
- extensive standard libraries and third party modules for virtually every task
- extensions and modules easily written in C, C++ (or Java for Jython, or .NET languages for IronPython)
- embeddable within applications as a scripting interface

Grundlegende Syntax von Python¹⁸

Bevor auf die syntaktischen Besonderheiten von Python eingegangen wird, sollte noch ein Augenmerk auf den interaktiven Interpreter von Python geworfen werden. Der Python- Interpreter arbeitet beim Ausfuhren eines Python-Scriptes zunachst klassisch:¹⁸

1. Einlesen der Datei (bzw. der interaktiven Eingabe)
2. lexikalische Analyse
3. syntaktische Analyse durch Parser, Ubersetzung in Bytecode
4. Interpretation des Bytecodes

Eine wesentliche Besonderheit von Python ist die Moglichkeit, den im dritten Schritt gewonnenen Bytecode separat abzuspeichern. Dieser Bytecode wird ublicherweise in Da teien mit der Endung .pyc abgelegt und ist vollstandig plattformunabhangig.¹⁹

Fur eine vollstandige Darstellung der Syntax von Python reicht der Rahmen dieses Arbeitsberichts nicht aus, hierzu wird deshalb auf van Rossum, G. (Februar 2008) und Hetland M. L. (2005) verwiesen. Ein kurzes Beispiel soll den einfachen Aufbau von Python Dieses kurze Beispiel zeigt die Einfachheit und Lesbarkeit von Python. Das Beispiel deklariert eine Klasse ,,Auto“ mit den privaten Attributen ,,Modell“, ,,PS“, ,,Hubraum“, ,,Hersteller“ - welches einen Defaultwert ,,BMW“ zugewiesen hat - und ”Baujahr” - eben- falls mit Defaultwert ,,2008“.

Auf die Darstellung der Setter wurde verzichtet. Die Getters getModell und getLeistung geben zum einen den Modellnamen zuriick und zum anderen die Leistungs- parameter des Autos mit „PS“ und ,,Hubraum“.

Die dargestellte Stringfunktion __str__ ist eine Python-Standardfunktion, mit der ein Objekt einer Klasse einen Output als String erzeugen kann - diese Klasse wird im gege- benen Fall iberschrieben und liefert somit ein Ausgabe ,,Hersteller: BMW, Modell: 330i“.

3.2 MVC-Architektur in Django

Wie in vielen anderen Web-Frameworks²⁰ auch, realisiert Django das MVC-Konzept zur Teilung von Logik, Inhalt und Layout. Es ist jedoch nur eine sehr lockere Implementierung genau in dem Umfang vorhanden, dass die eigentliche Entwicklung nicht durch besondere Einschrankungen behindert wird, aber immer noch so streng, dass der Programmierer nicht vollkommen vom MVC-Prinzip abweichen kann.

Holovaty A., Kaplan-Moss J. (2008) beschreiben den Einfluss der MVC-Architektur in Django wie folgt:²¹

Django follows this MVC pattern closely enough that it can be called an MVC framework. Here’s roughly how the M, V, and C break down in Django:

- M, the data portion, is handled by Django’s database layer [...]
- V, the portion that selects which data to display and how to display it, is handled by views and templates.
- C, the portion that delegates to a view depending on user input, is handled by the framework itself by following URLconf and calling the appropriate Python function for the given url.

Because the ” C” is handled by the framework itself and most of the excite­ment in Django happens in models, templates, and views, Django has been referred to as an MTV framework.

In the MTV development pattern,

- M stands for ’’Model”, the data access layer. This layer contains any­thing and everything about the data: how to access it, how to validate it, which behaviors it has, and the relationships between the data.
- T stands for ’Template”, the presentation layer. This layer contains persentation-related decisions: how something should be displayed on a Web page or other type of document.
- V stands for ”View”, the business logic layer. This layer contains the logic that accesses the model and defers to the appropriate template(s). You can think of it as a bridge between models and templates.

3.3 Die Verwendung von Django

Im folgenden Teil wird auf die Verwendung des Web-Frameworks Django eingegangen. Es werden die Installation, die Grundlagen von Django, das intere Django-Template-System und Django-Views, die Datenbank-API und das Admininterface betrachtet. Hierbei han- delt es sich um die allgemeinen Grundfahigkeiten von Django fiir die Entwicklung eines ersten Prototypen. Fir eine vollstandige Beschreibung des Funktionsumfangs von Django wird auf Django Foundation - Doc (2008) verwiesen.

3.3.1 Installation

Der Quellcode von Django ist in reinem Python-Code geschrieben, deshalb muss vor der Installation von Django eine funktionierende Python-Version auf dem System vorhanden sein. Django benotigt Python ab der Version 2.3. Um zu uberprufen, ob Python bereits auf dem System zur Verhigung steht, empfiehlt sich die Eingabe von python in die Kommandozeile/Terminals des jeweiligen Betriebssystems.

Ahnelt die Ausgabe nachfolgendem Code, ist Python auf dem System installiert:

Abbildung in dieser Leseprobe nicht enthalten

Listing 3.2: Python - Interaktiver Interpreter

Sollte Python auf dem System nicht installiert sein, wird an dieser Stelle auf Py­thon Software Foundation (2008) verwiesen. Django kann uber zweierlei Arten installiert werden, entweder liber ein stabiles Release (als tar.gz Datei) oder liber die Quellcodever- waltung Subversion8. Beide Wege sollen hier kurz dargestellt werden.

Installation eines offiziellen Releases

Diese Installationsvariante empfiehlt sich immer dann, wenn man auf einen absolut stabi- len Django-Code angewiesen ist. Django liegt zum momentanen Zeitpunkt in der Version 0. 96 vor.

Um Django als stabiles Release zu installieren, empfiehlt sich folgendes Vorgehen:

1. Herunterladen des aktuellen Releases von der Django Internetseite10
2. Entpacken der heruntergeladenen Datei (Linux: tar, Windows: 7-Zip)
3. Offnen der Kommandozeile und Wechsel in das erzeugte Verzeichnis
4. Installation mit Kommandozeilenbefehl: python setup.py install

Dieses Vorgehen installiert Django automatisch in das site-packages Verzeichnis der Python-Installation.

Installation der Entwicklerversion (aus Subversion)²²

Um aktuelle Bugfixes und Neuerungen der Django-Entwicklung in seinen Projekten zu beriicksichten, empfiehlt sich eine Installation von Django als Subversion-Checkout. Dies setzt eine Installation von Subversion voraus. Hierzu sollte folgendes Vorgehen beriick- sichtigt werden (zu beachten ware, dass sich folgende Ausfuhrung auf die Installation auf einem Linux-System beziehen, d.h. die Installation auf einem Windows-System kann sich an einigen Punkten unterscheiden):

1. Erstellen einer Ordnerstruktur

Abbildung in dieser Leseprobe nicht enthalten

Listing 3.3: Django - Ordnerstruktur

Abbildung in dieser Leseprobe nicht enthalten

Listing 3.4: Django - Subversion Checkout

Abbildung in dieser Leseprobe nicht enthalten

Listing 3.5: Django - Verlinkung in Python site-packages

4. django-admin.py ausfuhrbar machen

Abbildung in dieser Leseprobe nicht enthalten

Listing 3.6: Django - django-admin.py

Obiges Vorgehen installiert Django als Entwicklerversion auf einem Linux-System. Um den Django-Code zu aktualisieren reicht ein Ausfuhren von svn update im Django-Code- Verzeichnis.

Mittlerweile hat sich gezeigt, dass der zweite Weg zu bevorzugen ist, da der Django- Code trotz stuandiger Weiterentwicklung stabil gehalten wird und so dem Entwickler wert- volle Neuerungen nicht vorenthalten werden bzw. bleiben.

3.3.2 Django-Grundlagen

Python ist nach Holovaty A., Kaplan-Moss J. (2008) die einzige Voraussetzung fur ein funktionierendes Django. Dennoch liegt mit der Benutzung von Django das Augenmerk auf der Erstellung von dynamischen Webanwendungen und somit auch auf dem Einsatz von Datenbanken.

Django unterstutzt zum momentanen Zeitpunkt folgende Datenbanksysteme:

- PostgreSQL (http://www.postgresql.org)
- SQLite3 (http://www.sqlite.org)
- MySQL (http://www.mysql.com)

Neben den oben genannten Systemen bestehen bereits Anbindungen an Microsofts SQL-Server und Oracle-Datenbanksysteme. Diese Anbindungen sind allerdings noch nicht im aktuellen Release beriicksichtigt, aber liber die Entwicklerversion von Django schon zu testen.

Wie im einzelnen Datenbanken fur eine Django-Anwendung erzeugt werden, variiert stark vom gewahlten System, deshalb wird an dieser Stelle auf die jeweilige Dokumenta- tion der Systeme verwiesen.

Projektumgebung schaffen

Ein Projekt - im Django Sinne - ist eine Sammlung von Einstellungen fur eine Instanz von Django, einschliefilich Datenbankkonfiguration, Django-spezifischen Einstellungen und an- wendungsspezifischen Einstellungen.

Unter 3.3.1 wurde bereits eine Django-Struktur erstellt. Im Ordner projects wird nun folgender Code ausgefuhrt, um ein Django-Projekt zu erstellen.

Abbildung in dieser Leseprobe nicht enthalten

Listing 3.8: Django - Projektstruktur

Diese Dateien haben nachfolgende Aufgaben:

- —init py

Eine Datei, die von Python benotigt wird; behandelt das Verzeichnis als Package (als Sammlung von Modulen).

- manage.py

Ein Kommandozeilenprogramm, das den Benutzer auf verschiedene Arten mit Djan­go interagieren lasst.

- settings.py

Konfigurationsdatei fur das Django-Projekt

- urls.py

URLconf - Deklaration der URLs des Django-Projekts

Der Developement-Server

Nach dem Erstellen der Projektstruktur sollte als erstes die Funktionsfahigkeit der Django- Umgebung getestet werden. Dazu bedient man sich am einfachsten dem von Django mit- gelieferten Development-Server. Dabei handelt es sich um eine leichtgewichtige Webser- veranwendung, die fur die Entwicklung von Django basierten Seiten genutzt werden kann, ohne auf andere Systeme - wie Apache - zuruckgreifen zu mussen.

[...]

---

¹ Hyper Text Markup Language

² National Center of Supercomputing

³ rekursives Akronym fiir ,,PHP: Hypertext Preprocessor", urspriinglich ,,Personal Home Page Tools"

⁴ vgl. Holovaty A., Kaplan-Moss J. (2008)

⁵ Model View Controller

⁶ vgl. Gamma E., Helm R., Johnson R., Vlissides J. (1996)

⁷ Bachle M., Kirchberg P. (April 2007), Seite 79

⁸ naheres zu Subversion unter http://subversion.tigris.org

⁹ vgl. Django Foundation - Home (2008) 10http://www.djangoproject.com/

¹⁰ Hypertext Transfer Protocol

¹¹ Bachle M., Kirchberg P. (April 2007), Seite 79

¹² Application Programming Interface

¹³ vgl. Fowler M. (2004)

¹⁴ Don’t repeat yourself

¹⁵ Hunt A., Thomas D. (1999)

¹⁶ vgl. Hunt A., Thomas D. (1999)

¹⁷ bekannt etwa durch den Film ”Das Leben des Brian

¹⁸ Walter T. (2007), Seite 257

¹⁸ vgl. Hetland M. L. (2005), Seite 8ff

¹⁹ Walter T. (2007), Seite 262

²⁰ Hunt A., Thomas D. (1999), Seite 263

²² z.B.: RoR - Ruby on Rails

²² Holovaty A., Kaplan-Moss J. (2008), Seite 61f