Contents
In Python gibt es zwei große Webframeworks, die beide auf WSGI aufsetzen und in einer Art Konkurrenzkampf stehen. Beide sind mittlerweile bei Version 1 oder höher angelangt, doch es bleibt spannend, in welche Richtung sich die beiden Frameworks entwickeln.
Aktuell sind Frameworks an sich stark in der Diskussion, selbst Guido van Rossum fragt sich z.B., welches er nutzen möchte (nettes Statement dazu in einem Blog.) und hat inzwischen sein Placet für Django ausgesprochen (aber siehe auch hier, trotzdem geht die Entwicklung von Django und TurboGears aber unvermindert weiter und weitere Frameworks (z.B. Pylons) gewinnen ebenfalls an Popularität.
Welches Framework für wen?
Grundsätzlich gibt es zwei Arten von Frameworks. Einmal die "Batteries Included"-Variante wie Django, die reichlich Features bieten. Auf der anderen Seite gibt es die Minimalisten wie Werkzeug, CherryPy.
Welche Framework-Variante besser ist, kann man pauschal nicht beantworten. Es kommt zum einen darauf an, welche Web-Anwendung entwickelt werden soll und zum anderen, wie viel Zeit man investieren möchte. Möchte man z.B. eine Web-Applikation entwickeln in der es in erster Linie um Content-Management geht, ist ein Full-Featured Framework wie Django gut geeignet.
Der Vorteil von einer selbst zusammengestellten Auswahl der Komponenten liegt klar in der Flexibilität. Gleichzeitig ist das jedoch auch der größte Nachteil. Vor allem kostet es mehr Zeit. Man muss erstmal existierende Komponenten validieren. Es gibt keine zentrale Dokumentation. Es gibt mehrere Anlaufstellen zu den Entwicklern (z.B. fürs Bugtracking). Jede einzelne Komponente hat ihre eigenen Release-Zyklen, mit den man seine Applikation jeweils synchronisieren muss.
Hier noch mal ein paar Anhaltspunkte in der Übersicht:
- minimales Framework
- Vorteile
- flexibel, man kann frei Komponenten zusammenstellen/austauschen
- Einzelne Komponenten entwickeln sich meist schneller
- Evtl. näherer Kontakt zu den Entwicklern der Komponenten
- Nachteile
- mehrere Anlaufstellen (Dokumentation, Mailinglisten, Bugtracking usw.)
- verschiedene Release-Zyklen der Komponenten
- Debugging in verschiedenen Komponenten
- Zeitaufwendiger (validieren existierender Komponenten)
- Vorteile
- Batteries Included Frameworks
- Vorteile
- führt meist schneller zum Ziel
- zentrale Dokumention
- eine Anlaufstelle zur Community (Mailinglisten, Bugtracking usw.)
- Debugging nur in einem Framework und der Applikation
- nur ein Release-Zyklus, mit dem man synchronisieren muss
- Nachteile
- unflexibel, austauschen von Komponenten nur mit mehr Aufwand.
- meist längerer Release-Zyklus des Frameworks
- Vorteile
Links
Die Frage nach dem richtigen Framework taucht öfter im Forum auf, hier ein paar Threads dazu:
Gemeinsame Eigenschaften von Django und TurboGears
- automatische Code-Generierung zum schnellen Erzeugen eines neuen Projektes
- können sowohl über mod_python, SCGI und FastCGI oder Reverse proxying an Webserver (Apache, LigHTTPd, nginx, ...) angebunden werden
- unterstützen PostgreSQL, MySQL, SQLite
- unterstützen Internationalisierung
laufen mit Python >= 2.3
- Die meisten Komponenten können auch ohne großen Aufwand außerhalb von Django/TurboGears benutzt werden (zum Beispiel das ORM oder die Template-Sprache).
- unterstützen Sessions und Benutzerauthentifizierung
- vereinfachtes Erstellen von Newsfeeds (RSS, RDF, Atom)
Es ist möglich Komponenten auszutauschen. Wenn man zum Beispiel Djangos Template-Sprache nicht mag, kann Kid benutzt werden. Oft geht damit aber der Verlust von Funktionalität an anderer Stelle einher (z.B. Admin-Interface in Django oder CatWalk in TurboGears).
Django
Homepage: http://www.djangoproject.com
Ein weit verbreitetes Framework ist Django, welches mit Apache über mod_python und anderen WSGI kompatiblen Interfaces kommuniziert. Django wird von einem eng zusammen arbeitendem Team entwickelt und von Grund auf neu implementiert. Wichtige Komponenten sind z.B. a) ein eigener ORM für die Speicherung der Daten, welcher mit PostgreSQL, MySQL und SQLite zusammenarbeitet b) ein Template-System, das, im Gegensatz zu vielen anderen, nicht XML-basiert und bewusst einfach gehalten ist, damit Nicht-Programmierer gut damit klar kommen, und vor allem c) ein leistungsfähiges Framework zur einfachen Erstellung von Administrations-Interfaces.
Vorteile
- automatisch generierte Backendseiten (Admin-Interface) die auch recht weit an die eigenen Anforderungen anpassbar sind
- Mapping von URLs zu Handlern über Regular-Expressions
- integrierter Object-Relation-Mapper um Daten in die Datenbank abzuspeichern, für CRUD ziemlich komfortabel
- effizientes Cache-System (verschiedene Backends, unter anderem memcached)
- keine weiteren Python-Abhängigkeiten
- Middleware-Struktur
- durchdachte API
- Templatesprache mit den wichtigsten Feautures, die auch für nicht-Programmierer verständlich sein soll
- Unterstützung für Generic-Views (d.h. weniger Programmieraufwand um oft benötigte Seiten anzuzeigen)
- Flatpages (d.h. Seiten die direkt aus der Datenbank genommen und angezeigt werden)
kann Google-Sitemap-Dateien erstellen, somit ist es einfacher von Suchmaschinen indizierbar (Google Sitemap-Protokoll)
- "Entwicklerversion" ist problemlos verwendbar, da i.d.R. keine kritischen Fehler enthalten sind
- gute, umfangreiche und aktuelle Dokumentation, mehrere veröffentlichte Bücher
- die größte User-Community, im Vergleich zu anderen Web-Frameworks (englischsprachig)
gute Performance (auch wenn es schwer zu vergleichen ist, aber in einigen Tests war Django am schnellsten. Siehe hier und hier)
Nachteile
Django hat zwar die größte User Gemeinde, aber nur wenige Kernentwickler und wenige Commiter. So dauert es oft sehr lange bis eingerechte Patches auch wirklich in den Trunk aufgenommen werden. Das hat zur folge, dass Bugs oft monatelang nicht gefixt werden (siehe Upload-Problem im Blog-Eintrag (en)). Auch beim Implementieren von neuen Features ist die Entwicklung relativ langsam. Es gibt einige sehr interessante branches, die leider nur vor sich hin dümpeln.
Dass einige Bugs schneller gefixt werden und bestimmte Features implementiert werden, liegt wohl u.a. daran, weil die meisten Hauptentwickler bei der Firma World Online Django entwickeln. World Online betreibt drei große News-Webseiten und verkauft die eingesetzte Django-Applikation Ellington CMS für 15.000 - 35.000 Dollar.
- bringt bisher keine offizielle AJAX-Funktionalität mit (kan auch als Vorteil gesehen werden)
- seltene Releases
- Nutzt keine vorhandene Open Source-Lösungen, sondern erfindet das Rad hin und wieder neu.
- läuft zwar mit Python 2.3, die Unterstützung hinkt aber etwas der für Python 2.4 hinterher.
- Installation ohne Shell-Zugang kompliziert und nicht dokumentiert.
- Django Middlewares sind leider keine WSGI-Middlewares
- Das ORM ist nur mittelmäßig, für komplexere Systeme würde man eher zu SQLAlchemy raten, was von Django nicht unterstützt wird (viele Vorteile gehen somit verloren)
- Die Templatesprache ist für komplexere Sachen zu beschränkt, man kann sie aber durch Jinja ersetzen
Links
Pylons
Homepage: http://pylonshq.com/
Auf der Basis von Paste bietet Pylons kein Webframework im Sinne von Django, sondern stellt vielmehr eine Art Toolkit für eigene WSGI Anwendungen bereit. Die Kernfunktionalität von Pylons selbst ist gering, außer einem guten Debugger und grundlegendem Code für Request-Handling wird dem Entwickler kaum etwas geboten. Umso mehr ist eine Pylons-Anwendung daher auf externe Komponenten für Sessions und Routing, Form-Handling, Templating, Datenbankzugriff und Authentifzierung angewiesen. Pylons legt den Entwickler in der Wahl dieser Komponenten nicht fest, sondern legt Wert auf größtmögliche Flexibilität. Zwar bindet Pylons einige Komponenten wie Routes und Beaker standardmäßig in neue Anwendungen ein, diese können jedoch mit wenig Aufwand ausgetauscht werden. Bei anderen Komponenten wie Form-Handling ist dem Entwickler – auch wenn die Dokumentation einige Komponenten empfiehlt – die Wahl völlig frei gestellt, bereits beim Anlegen einer neuen Anwendung wird der Entwickler nach der zu verwendenden Template-Engine gefragt.
Ob und in wie weit dies von Vor- oder Nachteil ist, hängt von der Art des Projekts und den persönlichen Vorlieben des Entwicklers ab. Für die größere Flexiblität bezahlt man mit erhöhtem Entwicklungsaufwand, da man die Komponenten selbst integrieren muss, und mit dem Fehlen vorgefertigter Komponenten wie der Django-Administrationsanwendung. Besonders bei einfachen CRUD-Anwendungen dürfte sich dies eher negativ auf die Produktivität auswirken. Auf der anderen Seite ist man in der Auswahl der Komponenten nicht festgelegt und hat so mitunter bessere Komponenten zur Hand.
Als Neueinsteiger in Pylons sollte man auf die noch nicht veröffentlichte Version 0.9.7 zurückgreifen, da sich gegenüber älteren Versionen einiges geändert hat. Vor allem die Dokumentation hat sich wesentlich verbessert.
TurboGears
Homepage: http://www.turbogears.org
Im Gegensatz zu Django verwendet TurboGears bereits vorhandene Komponenten und fügt diese zu einem sog. "Meta-Framework" mit vergleichbarer Funktionalität zusammen:
CherryPy HTTP-Framework als Server
SQLObject für Datenbankanbindung
- Unterstützt MySQL, PostgreSQL, SQLite, Firebird, Sybase, MAX DB (SAP DB), MSSQL und ADODBAPI
Kid als Template-Engine
FormEncode zur Validierung und Konvertierung von Daten aus Client-Requests und der Datenbank.
MochiKit, eine JavaScript-Bibliothek
Vorteile
- Viele Komponenten lassen sich leicht austauschen (z.B. SQLObject vs. SQLAlchemy, Kid vs. Genshi/Cheetah)
Eigener Applikationsserver (CherryPy) mit eingebautem Webserver macht Testen und Deployment für simple Fälle sehr einfach
CherryPy Filter-System (z.B. Speicher-Cache, Header-Modifizierung, Sessions, Identity)
Stärkere Orientierung an Gepflogenheiten der Python-Welt (Pythonicity)
ModelDesigner - ein Web-basierender Code Generator-Tool um SQLObject-Models zu erstellen.
Web Console - ein Python Webshell-Tool
Catwalk - ein Tool ähnlich wie Djangos Admin-Seiten (Stimmt das so???)
Nachteile
TG befindet sich gerade in einer Umbruchphase von 1.0 zu 2.0, bei der sich einiges ändert. So wird das neue TG 2.0 Pylons als Grundlage nutzen und sich von einigen Komponenten die sich nicht bewährt haben verabschieden. Siehe auch pylons-discuss Maillinglisten-Thread oder turbogears Maillinglisten-Thread
- Dokumentation stellenweise noch unausgegoren
- keine einheitliche API
nur mittelmäßige Performance (Hier wären vielleicht Referenzen zu entspr. Benchmarks angebracht, ansonsten ist dies nur eine unbewiesene Behauptung.)
Anmerkung: inzwischen ist Turbogears 2 erschienen, das doch einige Änderungen mit sich bringt
Bottle
Bottle ist ein kompaktes Micro-Framework speziell für kleinere Projekte und Web APIs. Es ist in einer einzigen Datei verpackt und hat keine Abhängigkeiten (abgesehen von der Python Standard Library). Trotzdem ist alles Wichtige bereits eingebaut: HTTP Server, Template-Engine, Key/Value Datenbank, POST, GET und Cookie Datenverarbeitung, URL Routen und einiges mehr.
Vorteile
- Alles in einer Datei. Keine (harten) Abhängigkeiten. Sehr einfach zu handhaben.
- HTTP Server, Template-Engine und Key/Value Datenbank sind eingebaut, können aber leicht durch mächtigere Alternativen (cherrypy, flup, fapws3, mako, SQLAlchemy) ersetzt werden.
- Ziemlich performant im Vergleich zu den großen Frameworks.
Nachteile
Sehr neue und kleine Community. Die Dokumentation gibt es nur in englisch, obwohl es ein deutsches Projekt ist.
- Noch in der Entwicklungsphase. Häufige Updates (kann auch als Vorteil gesehen werden). Keine 'stable' Releases.
Flask
Flask erhebt genau wie Bottle den Anspruch, ein Micro-Framework zu sein. Allerdings liegt der Fokus bei Flask nicht auf der Größe des Framework-Codes, sondern auf der Größe der Anwendungen, die damit typischer Weise entwickelt werden sollten. Flask basiert auf dem WSGI-Framework Werkzeug und der Template-Engine Jinja2.
Vorteile
- Sehr ausführliche Dokumentation. Neben der Entwicklung einer Beispielanwendung, der Besprechung der wesentlichen Komponenten gibt es auch einen Abschnitt für gängige Design-Pattern im Umgang mit Flask.
Flask kann durch Extensions erweitert werden. Es existieren bereits eine Vielzahl davon, z.B. für die Datenbankanbindung mittels SQLAlchemy, für dokumentenbasierte DBs wie CouchDB oder MongoDB oder auch für die Integration für das WTForms-Modul.
Komfortables Debugging dank integrierter Shell im Debug-Modus.
- Basiert auf bereits weitläufig verwendeten Projekten (Werkzeug und Jinja2).
Nachteile
Ähnlich zu Bottle ist Flask ein relativ junges Projekt (begonnen 2010).
- Im Gegensatz zu Bottle besitzt es Abhängigkeiten, was die Installation aufwendiger macht.
Karrigell
Karrigell ist ein kleines Framework, das ein wenig ASP gleicht. Mehr Infos und ein Beispielskript sind im Forum.
Vorteile
- Gut geeignet für Einsteiger
Nachteile
Nicht WSGI konform
- Nicht für den Shared-Webhostingbereich geeignet.
web.py
Homepage: http://webpy.org/
Das Framework stellt sich folgendermassen vor: "web.py is a web framework for python that is as simple as it is powerful. web.py is in the public domain; you can use it for whatever purpose with absolutely no restrictions."
GlasHammer
Homepage: http://glashammer.org/
Glashammer positioniert sich in etwa zwischen Django und Pylons und basiert auf den Komponenten Werkzeug, Jinja2 und WTForms. Der Rest ist pylons-like frei wählbar, aber mit vielen Optimierungen, die einem das Leben einfach machen.
web2py
Homepage: http://www.web2py.com bzw. http://code.google.com/p/web2py/
Web2py ist nach Ansicht einiger Foren-Autoren nicht empfehlenswert, siehe:
Vorteile
- Kurze, einfache Syntax
- Webinterface für Installation, Verwaltung und Entwicklung
- Für Freunde der Kommandozeile: Statt des Webinterface kann alternativ komplett auf der Kommandozeile entwickelt werden
- Autor liefert zwei brauchbare Anwendungen dazu:
Nachteile
- Nur ein Hauptentwickler, kleine Community
- Nur eine Dokumentation (Buch / PDF)