Webframeworks: Die höchste Kunst der Webprogrammierung?

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Dienstag 3. März 2009, 14:59

Ich weiß nicht warum immer wieder gesagt wird, das man in django keine Freiheiten hätte... Das stimmt so nicht. Django ist sehr modular aufgebaut. Mann kann alle Komponenten austauschen/ersetzten. Natürlich hat man dann nicht mehr den Komfort, aber das hat man auch nicht, wenn man direkt ein Framework nutzt, welches wenig Komfort Features hat ;)

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
lunar

Dienstag 3. März 2009, 15:23

Django ohne Django's Komponenten ist aber irgendwie witzlos ... zumal das Austauschen von Komponenten innerhalb eines Frameworks immer noch etwas anderes ist als eine Anwendung komplett selbst zusammenzubauen, wie man es bei Werkzeug kann. Und mit aller Gewalt gegen das Framework zu programmieren, ist auch selten ratsam.
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Dienstag 3. März 2009, 15:26

schwarz/weiß oder was?

Natürlich ist ein Framework witzlos, wenn man alle seine Komponenten nicht nutzt... Werkzeug wäre auch sinnlos, wenn man keine Features davon nutzt ;)

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
Hyperion
Moderator
Beiträge: 7472
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Dienstag 3. März 2009, 15:35

Wie sieht es denn aus, wenn ich bei Django SQLAlchemy und Jinja2 nutzen wollen würde? Klappt das ganze automatische Admin-Interface dann noch? Oder muss ich mich dann darum selber kümmern?
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Dienstag 3. März 2009, 15:36

Ich persönlich habe bei Django auch die Templatenegine gegen Jinja ausgewechselt. Habe dann aber das Problem, das etwaige andere eingebundene Projekte dennoch Django-Templates benötigen und ich das nicht so einfach integrieren kann. Das Problem hätte ich aber mit Pylons genauso.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
lunar

Dienstag 3. März 2009, 15:39

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.
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Mittwoch 4. März 2009, 10:15

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*
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.

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
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Mittwoch 4. März 2009, 10:20

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?
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.

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
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 4. März 2009, 10:32

IMHO könnte man einfach SQLAlchemy und Jinja2 parallel in seinen eigenen views nutzten. Wobei man dann zwei Modelle pflegen müßte...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Mittwoch 4. März 2009, 10:34

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.
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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Mittwoch 4. März 2009, 10:35

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
farid
User
Beiträge: 95
Registriert: Mittwoch 8. Oktober 2008, 15:37

Freitag 27. März 2009, 00:06

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.
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.

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. ;)
ogurek
User
Beiträge: 6
Registriert: Samstag 28. Februar 2009, 20:02

Samstag 2. Mai 2009, 08:24

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 :)
lunar

Samstag 2. Mai 2009, 10:39

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 :)
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Sonntag 3. Mai 2009, 18:34

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
Antworten