Der Trend zu Webapplikationen zwingt einstige HTML-Künstler ins Programmiererlager. Nur, wo schaut man sich einen guten und effizienten Stil ab? Der folgende Artikel beschreibt, wie ein Python-Guru mit Hang zu einem gewissen Django und ein PHP-Papst eine von der Redaktion vorgegebene Aufgabe lösen.

Mit PHP oder in Python/Django, womit lassen sich Webanwendungen schneller und eleganter erstellen? Zeev Suraski sowie Douglas Napoleone im Auftrag von Guido van Rossum versuchten sich an einer Standard-Anwendung, einer einfachen Musikdatenbank (vergleiche Kasten “Aufgabenstellung”). Der Code steht unter [1] zum Download bereit.

Django und Python

Im Umfeld von Python hat der Entwickler die Auswahl gleich aus einer ganzen Reihe von Frameworks, darunter Django [2], SQLAlchemy [3], Storm [4] oder ZoDB [5], die jeweils einen verschiedenen Fokus haben. Die Einsendung von Douglas Napoleone, nutzt das weit verbreitete Django in der Version 0.96, das die meisten Linux-Distributionen als Paket »python-django« mitbringen. Als Napoleone die Aufgabenstellung las, stellte er die kühne These auf, die Aufgabe lasse sich in unter einer Stunde lösen.

Angestellt als Senior Speech Research Engineer bei Nuance Communications, arbeitet er am modularen Spracherkennungssystem “Dragon Naturally Speaking”. Zum Testen seiner Software verwendet er oft Python und nutzt ein Fünftel seiner Arbeitszeit dazu, die Sprache zu erweitern. Napoleone organisiert darüber hinaus User-Konferenzen wie die Pycon US.

Der Amerikaner verwendet die stabile Version 0.96 von Django, die sich in Details von ihren Vorgänger- und Nachfolgerversionen unterschiedet, die Website dokumentiert sie ausführlich. Das Framework bringt seinen eigenen kleinen Entwickler-Webserver mit, sodass der Entwickler in der Entstehungsphase keinen Apache oder anderen Server zusätzlich konfigurieren braucht.

Ein neues Projekt richtet Napoleone mit »django-admin.py startproject Projekt« ein. Das Tool liegt im »bin«-Pfad der Django-Distribution und richtet ein Verzeichnis Dateien ein. In diesem Verzeichnis führt der US-Amerikaner »django-admin.py startapp Anwendungsname« aus, was weitere Dateien erzeugt.

Dort bearbeitet der Programmierer »settings.py«, um die Datenbank anzubinden; für populäre hat Django bereits Templates vorbereitet. Dank SQLite reicht eine lokale Datei im Filesystem zum Speichern kleiner Datenmengen. Weiterhin trägt er in »INSTALLED_APPS« noch »django.contrib.admin« und die eigene Anwendung »jukebox« ein.

Die Uhr tickt: Projektstart

Im Verzeichnis der Applikation liegt die Datei »models.py«, die Napoleone ebenfalls anpasst, um das Datenmodell zu beschreiben (siehe Listing 1). Die Angaben lassen sich direkt aus einem bestehenden Datenmodell ableiten. Attribute definieren bereits die Reihenfolge der Sortierung (»ordering«) oder das Format der Daten (etwa »NumberIsInRange(1000, 9999)« für die Jahreszahl).

Ist das Datenmodell spezifiziert, legt »manage.py syncdb« im Projektverzeichnis alle Tabellen der Datenbank an und fragt gleich nach einem Benutzer für die Authentisierung der Anwendung. Die Applikation ist nun schon bereit und der Entwickler startet den eingebauten Webserver mit »manage.py runserver«. Ein Browser zeigt unter [http://localhost:8000] bereits die Anmeldemaske und anschließend die Anwendung (Abbildung 1).

Abbildung 1: Django braucht lediglich ein Datenmodell und Filterregeln für eine benutzbare Weboberfläche.

Das Framework legt pro Tabelle eine Such- und Darstellungsmaske an, die der Programmierer über das Modell feiner konfiguriert. Hier sind die grundlegenden Datenbankoperationen schon eingebaut, Datensätze lassen sich hinzufügen, löschen oder in der Detailansicht modifizieren. Tabellenansichten sind sortierbar oder nach Suchbegriffen filterbar, ohne dass der Entwickler dazu nennenswerten Code verfassen muss.

Um initiale Daten in die Anwendung zu laden, verwendet Napoleone so genannte Fixtures, die er im JSON-Datenformat [6] in der Datei »fixtures/initial_data.json« anlegt. Sie lädt die Applikation als initiale Daten bei einem Neustart; Änderungen, die Benutzer vornehmen, landen aber in der SQLite-Datei, die in »settings.py« konfiguriert ist.

Fix am Ziel

Die Kürze der Zeit, die ein erfahrener Python-Entwickler benötigt, um eine Webapplikation mit Hilfe von Django zum Laufen zu bringen, beeindruckt. Napoleone hat es tatsächlich in weniger als einer Stunde geschafft, die geforderten Funktionen zu implementieren, obwohl er, wie er extra anmerkt, dies ohne weitere Vorbereitungen und mit einem gewissen Maß an Schlafmangel getan hat. Die komplette Sitzung, wie er die Anwendung zusammenbaut, hat er in einem Video dokumentiert, dass unter [7] auf Linux-Magazin Online anzusehen ist.

PHP pur

PHP ist von Grund auf für das Web konzipiert. Kleine Applikationen wie die vorgegebene Programmieraufgabe sind damit auch ohne Frameworks zu realisieren. So verzichtet der zweite Einsender, Zeev Suraski, (siehe Teil 1 des Schwerpunkts) auch darauf.

Aus Gründen der Übersichtlichkeit hat er Modell, View und Controller gemeinsam implementiert, Programmlogik und PHP-Code sind nicht streng getrennt. Wer das MVC-Design unter PHP beherzigt, um Kooperation von Webdesigner und Programmierer zu erleichtern, würde dagegen eines der zahlreichen PHP-Frameworks zu Hilfe [8] nehmen.

Das Deployment einer PHP-Anwendung erschöpft sich normalerweise darin, den Code in das Webroot zu kopieren und die Datenbank einzurichten. Die Jukebox von Zeev Suraski nutzt für die Kommunikation mit der Datenbank die PHP-Erweiterung PDO, die vom Backend abstrahiert. Für den Wechsel der Datenbank ist lediglich die PDO-Daten-URL in der Konfiguration anzupassen und ein PDO-Treiber zu installieren.

Das sollte eigentlich über PEAR [9], der PHP-Entsprechung zu Perls CPAN-Repository sofort gelingen, scheiterte jedoch in der Redaktion unter Suse 11.0 und Ubuntu 8.04: In beiden Fällen startete Apache nach der Installation der Erweiterungen nicht mehr. Das Logfile wies Einträge mit undefinierten Symbolen aus den PEAR-Erweiterungen auf, die erst verschwanden als alle Datenbanktreiber aus mit der Distribution gelieferten Datenbanktreiber entfernt waren.

Zeev Suraski teilt seinen Code in zehn Dateien in die Unterordner aus Abbildung 2 auf. Die Startseite »index.php« liefert die Songliste aus Abbildung 3. Der Code »$songs = JukeboxSongList($filters, $searchSubstrings)« filtert die Daten nach eingegeben Begriffen.

Abbildung 2: Die PHP-Lösung teilt den Code in überwiegend der darstellende Komponenten und reine Programmlogik. Der Einfachheit halber hält sie sich jedoch nicht streng an das MVC-Schema.

Abbildung 3: Eine einfache Musikdatenbank, wie sie jeder kennt.Die Umsetzungdes von Anfang an an der Entwicklung von PHP Beteiligten Zeev Suraski ist dennoch spannend.

Mehr Gewicht

Der Rest der Datei »index.php« besteht im Wesentlichen aus dem HTML-Code für das Formular und die Tabelle. »JukeboxSong.php« definiert die Klasse »JukeboxSong«, die den Kern der Programmlogik bildet. Ein seit PHP 5 im Sprachumfang enthaltener Konstruktur initialisiert ein Array für die Datenfelder.

Der PHP-Code fällt länger aus als die Python-Lösung, braucht aber kein Framework. Ein großer Teil des Codes besteht aus HTML. Der für PHP 5 geschriebene Code weist die Sprache als leistungsfähig und modern aus: Er kapselt die Datenstrukturen in einem Objekt und nutzt das neue Error-Handling. Mit der Datenbank kommuniziert Zeev Suraski ebenfalls objektorientiert und wirft so den Ballast der eigenwilligen Syntax alter Extensions über Bord.