Webframeworks: Die höchste Kunst der Webprogrammierung?
-
lunar
Es gibt Komponenten, die man in Django nicht so einfach ersetzen kann. Der Einsatz von Werkzeug ist nicht weniger sinnvoll, wenn ich auf Mini Templates verzichte. Ersetze ich aber Djangos Session-Verwaltung oder gar das ORM, verliere ich viel der eingebauten Funktionalität, so dass es überhaupt fraglich ist, ob der Einsatz von Django irgendeinen Vorteil bringt.
Ich würde sagen: WSGI ist viel zu einschränkend. Am besten nimmt man nur die Socket-Schnittstelle und baut den Rest selbst. Dann hat man volle Kontrolle über das HTT-Protokoll. Etwas quälend ist natürlich nur, dass man immer noch an Python gebunden wird. Eine fast unerträgliche Abhängigkeit, kann ich mir vorstellen. Daher sollte man sich am besten auch hier etwas eigenes suchen.... will sagen: Ich verstehe diesen Freiheitsdrang nicht.zero-one hat geschrieben:na wenn du so drauf bist... dann go for "Werkzeug" da musst du viel lernen und hast die totale freiheit ;-) ... wenn du noch mehr lernen willst und noch mehr freiheit... nimm direkt WSGI ;-) *duck und rennt*
Der Vorteil von Django als (relativ) vollständiges Webrahmenwerk liegt IMHO darin, dass es erstens eine große Community gibt und zweitens viele fertige Anwendungen, die man wiederverwenden kann - was nur möglich ist, da man sich auf gemeinsame Standards geeignet hat.
Stefan
Nein. contrib.admin braucht insbesondere contrib.auth (eine Abhänigkeit, die mich nervt) und damit reicht es nicht, einfach die richtigen Methoden für die Metadaten in von SQLAlchemy verwalteten Modellen zu definieren, sondern man müsste wohl noch einiges mehr monkey-patchen.Hyperion hat geschrieben:Wie sieht es denn aus, wenn ich bei Django SQLAlchemy und Jinja2 nutzen wollen würde? Klappt das ganze automatische Admin-Interface dann noch?
In wie weit Jinja2 zu Django kompatibel ist, weiß ich nicht, aber contrib.admin kommt natürlich mit einer Reihe von Templates, die alle davon ausgehen, dass es Django-Templates sind.
Wenn man auth, admin, Templates und ORM weglässt, bleibt eigentlich nichts mehr von Django übrig. So genial ist die Abbildung von URLs auf Views (aka Controllers) nun auch nicht, das könnte man dann auch noch selbst machen.
Bei Django muss man sich IMHO schon auf die vorhandenen Komponenten einlassen. Sie sind vielleicht nicht immer großartig, aber in der Summe spielen sie ihre Stärke aus und sorgen dafür, dass man (ich schrieb das eben schon) viele andere fertige Lösungen bekommt.
Stefan
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Funktioniert ziemlich gut und es kommt zu keinerlei Konflikten zwischen Django-Templates und Jinja-Templates. Kann ich eigentlich so empfehlen, denn die Templates von Django fand ich mit Abstand am störendsten. Wobei es sicherlich für die meisten Applikationen reicht und eigentlich gar nicht so schlecht sind. Jinja ist nur eben viel angenehmer zu nutzen und zu erweitern und gerade die Teile die mir in Django gefehlt haben bietet Jinja so an wie ich sie haben wollte. Somit habe ich einige eigene Tags einfach einmotten können und auf die Hooks die Jinja bietet migrieren können.sma hat geschrieben:In wie weit Jinja2 zu Django kompatibel ist, weiß ich nicht, aber contrib.admin kommt natürlich mit einer Reihe von Templates, die alle davon ausgehen, dass es Django-Templates sind.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Oder aber man schaut, dass man automatisch die für SQLAlchemy notwendigen Mappings aus den Metadaten der Django-Modelle generieren kann. Das dürfte nicht sonderlich schwer sein.
Allerdings beschränkt man sich dann auf Möglichkeiten von Django, hat also immer noch nicht z.B. zusammengesetzte Primärschlüssel.
Nachdem Djangos ORM jetzt aber endlich auch Aggregatfunktionen hat und man so Dinge wie "update set a = a + 1" machen kann, bin ich eigentlich damit jetzt zufrieden.
Stefan
Allerdings beschränkt man sich dann auf Möglichkeiten von Django, hat also immer noch nicht z.B. zusammengesetzte Primärschlüssel.
Nachdem Djangos ORM jetzt aber endlich auch Aggregatfunktionen hat und man so Dinge wie "update set a = a + 1" machen kann, bin ich eigentlich damit jetzt zufrieden.
Stefan
Als relativ lightweight Webframework mit ORM-backend finde ich Django eigentlich richtig gelungen. Ich nutze es auch immer wieder in verschiedenen Projekten: die Entwicklung ist zügig, und -- noch wichtiger -- der Pflegeaufwand hält sich in Grenzen.sma hat geschrieben:Der Vorteil von Django als (relativ) vollständiges Webrahmenwerk liegt IMHO darin, dass es erstens eine große Community gibt und zweitens viele fertige Anwendungen, die man wiederverwenden kann - was nur möglich ist, da man sich auf gemeinsame Standards geeignet hat.
Außerdem bin ich da zuversichtlich, die Projekte notfalls auf andere Webframeworks migrieren zu können, sollte es jemals erforderlich werden. Nichs ist schlimmer, als an ein Framework gekettet zu sein, das irgendwann mal von seinen Entwicklern nicht mehr richtig gepflegt wird. Django ist z.Zt. ja sehr aktiv (zum Glück), aber es hat schon andere Frameworks gegeben, die nach und nach verlassen wurden. Da ist Vorsorge keine schlechte Idee.
So da bin ich wieder - hatte in den letzten Wochen leider überhaupt keine Zeit, mich weiter mit dem Thema zu beschäftigen. Also zunächst schon einmal ein großes Danke für die vielen Eindrücke, die ihr mir vermittelt habt.
Wie bereits geschrieben habe ich zwar noch keine Erfahrung mit Python und solchen Frameworks und doch den Ehrgeiz, mir Werkzeug genauer anzuschauen. Ohne Zweifel wohl ein schwierigerer Einstieg als bei Django, aber dennoch machbar denke ich.
Wo sich mir allerdings noch ein Problem stellt - Werkzeug selbst ist ja bekanntlich nur eine Bibliothek. Verwende ich dieses allerdings z.B. in Kombination mit Jinja und sqlalchemy, kann ich dann nicht auch schon von einem Framework sprechen?
In wie fern ergeben sich wirkliche Unterschiede bei der Programmierung z.b. mit Werkzeug und derer mit Django?
Automatisiert einem das eine die Erstellung der Ordnerstruktur (beispielhaft)?
Wo kann man noch konkrete Unterschiede in der Art der Programmierung sehen?
Und wieder ein herzlichen Danke
Wie bereits geschrieben habe ich zwar noch keine Erfahrung mit Python und solchen Frameworks und doch den Ehrgeiz, mir Werkzeug genauer anzuschauen. Ohne Zweifel wohl ein schwierigerer Einstieg als bei Django, aber dennoch machbar denke ich.
Wo sich mir allerdings noch ein Problem stellt - Werkzeug selbst ist ja bekanntlich nur eine Bibliothek. Verwende ich dieses allerdings z.B. in Kombination mit Jinja und sqlalchemy, kann ich dann nicht auch schon von einem Framework sprechen?
In wie fern ergeben sich wirkliche Unterschiede bei der Programmierung z.b. mit Werkzeug und derer mit Django?
Automatisiert einem das eine die Erstellung der Ordnerstruktur (beispielhaft)?
Wo kann man noch konkrete Unterschiede in der Art der Programmierung sehen?
Und wieder ein herzlichen Danke
-
lunar
Selbst wenn du Werkzeug mit anderen Bibliotheken für den Datenbankzugriff und das Templating verbindest, schafft das noch kein Framework, allenfalls entwickelst du dein eigenes Miniframework.
Ein Framework unterscheidet sich von einer Bibliothek dadurch, dass es Eintrittspunkte für die Anwendung zur Verfügung stellt und Standard-Funktionen zum Zugriff auf Session-Daten, Templates und Datenbank bringt.
Bei einem Werkzeug-Projekt musst du alles selbst programmieren. Du musst die Eintrittsfunktion der Anwendung selbst schreiben, das WSGI-Environment selbst in einen Request umsetzen, das URL-Routing selbst durchführen, die View-Funktionen oder Controller-Klassen selbst aufrufen, die Datenbankverbindung selbst konfigurieren, die Template-Engine einrichten, und so weiter und so fort. Django dagegen verbindet selbstständig zur Datenbenk, konfiguriert das Templating automatisch, stellt eine Eintrittsfunktion zur Verfügung, etc.
Im Allgemeinen musst du bei Django wirklich nur Modell und View implementieren, bei Werkzeug ist auch das Ganze drumherum deine Aufgabe. Probiere beide Ansätze doch mal aus, dann merkst du den Unterschied schon
Ein Framework unterscheidet sich von einer Bibliothek dadurch, dass es Eintrittspunkte für die Anwendung zur Verfügung stellt und Standard-Funktionen zum Zugriff auf Session-Daten, Templates und Datenbank bringt.
Bei einem Werkzeug-Projekt musst du alles selbst programmieren. Du musst die Eintrittsfunktion der Anwendung selbst schreiben, das WSGI-Environment selbst in einen Request umsetzen, das URL-Routing selbst durchführen, die View-Funktionen oder Controller-Klassen selbst aufrufen, die Datenbankverbindung selbst konfigurieren, die Template-Engine einrichten, und so weiter und so fort. Django dagegen verbindet selbstständig zur Datenbenk, konfiguriert das Templating automatisch, stellt eine Eintrittsfunktion zur Verfügung, etc.
Im Allgemeinen musst du bei Django wirklich nur Modell und View implementieren, bei Werkzeug ist auch das Ganze drumherum deine Aufgabe. Probiere beide Ansätze doch mal aus, dann merkst du den Unterschied schon
Faustregel, um ein Rahmenwerk zu erkennen: Der Code funktioniert nach dem "don't call us, we call you"-Prinzip und ist alleine nicht lauffähig. Typischerweise erbt man von irgendetwas, registriert irgendwo Funktionen oder fügt sich sonst irgendwie in ein größeres ganzes ein.
Stefan
Stefan
Wenn dir das Verständnis des Web nicht so wichtig ist, kannst du mit einem fertigen Framework loslegen. So etwas wie Werkzeug ist insbesondere dann interessant, wenn man den Weg und Zusammenhang vom eigenen Applikationscode bis zum fertigen HTML im Browser einigermaßen verfolgen und verstehen will. Für das Lernen ist es sehr hilfreich und für viele, die eher in der CGI-Ecke ihre Wurzeln haben, gewissermaßen der nächste logische Schritt.
Zur Alberei "direkt auf WSGI aufsetzen": Ein Framework muss nicht sein und WSGI ist eine tolle Schnittstelle (die in Rubys Rack 1.0 noch schöner geworden ist), aber ich sehe es nur als vernünftig an, auf ein bestehendes paar aus Request- und Response-Klassen in Python zu setzen, denn die können (und sollten) sehr viel der schmutzigen Details und Macken auffangen, die sich in der Gegend von HTTP so ergeben. Header muss man nicht selbst verarbeiten und ich bin jedes Mal erstaunt, wie viel man bspw. bei Dateiuploads falsch machen und noch verbessern kann. Werkzeug ist für mich diese absolute und IMHO saubere Grundlage für Web-Apps in Python.
Wenn's etwas mehr Framework sein darf, ist Glashammer vielleicht eine Option. Da gefällt mir allerdings die Abstraktion des URL-Mappings noch nicht so ganz (weil die Kompatibilität/Portierbarkeit wegfällt), auch wenn das aus Anwendersicht gut gemeint ist.
Zur Alberei "direkt auf WSGI aufsetzen": Ein Framework muss nicht sein und WSGI ist eine tolle Schnittstelle (die in Rubys Rack 1.0 noch schöner geworden ist), aber ich sehe es nur als vernünftig an, auf ein bestehendes paar aus Request- und Response-Klassen in Python zu setzen, denn die können (und sollten) sehr viel der schmutzigen Details und Macken auffangen, die sich in der Gegend von HTTP so ergeben. Header muss man nicht selbst verarbeiten und ich bin jedes Mal erstaunt, wie viel man bspw. bei Dateiuploads falsch machen und noch verbessern kann. Werkzeug ist für mich diese absolute und IMHO saubere Grundlage für Web-Apps in Python.
Wenn's etwas mehr Framework sein darf, ist Glashammer vielleicht eine Option. Da gefällt mir allerdings die Abstraktion des URL-Mappings noch nicht so ganz (weil die Kompatibilität/Portierbarkeit wegfällt), auch wenn das aus Anwendersicht gut gemeint ist.