gerold hat geschrieben:Ich habe vor kurzem ein Plone-Projekt, an dem ich wochenlang programmiert habe, hingeschmissen. Ich weiß, das ist nicht rühmlich, aber ich hatte mich festgefahren. Ich setzte hauptsächlich Automatismen wie z.B. Archetypes ein. Das war mein Fehler. Zuerst änderte sich die API nach einem Update auf ein neueres Plone. Das konnte ich noch in den Griff bekommen. Dann musste ich für jede Kleinigkeit, die ich außerhalb des Archetypes-Frameworks anpassen wollte, geeignete Hook-Punkte finden. Und bei jeder Änderung dachte ich mir, wie leicht ich das ohne Archetypes geschafft hätte und wieviele Tage ich jetzt damit verbrachte, herauszufinden, wie ich Archetypes teilweise umgehen könne.
Ja, sich auf APIs verlassen, die sich ändern ist natürlich sehr unpraktisch und ärgerlich, da stimme ich dir absolut zu. Aber ich muss zugeben, dass in der Zeit die ich mit Django verbracht habe sich die API nur einmal stark geändert hat (für Eingeweihte: magic-removal). Aber es ist nicht so, dass es sich von einem Moment auf den anderen verändert hat: man konnte die neue API schon vorher ausgiebig testen und es gab Wiki-Seiten auf denen die Migration haarklein beschrieben war. Im Moment sind keine wirklich großen Änderungen in Sicht und ab Version 1.0 wird die API wohl quasi fest wie Beton sein (was natürlich andererseits auch Problematisch sein kann).
Das Umgehen der Automatismen ist natürlich so eine Sache: Automatismen sind genau dann praktisch, wenn man genau das macht, was sich der Autor des Automatismus gedacht hat gedacht hat. Deswegen hat auch Rails viel Magic, viel mehr als Python-Programmierer gerne haben und man kommt damit schneller zu ergebnissen als mit Python-Frameworks. Dies macht natürlich anfänglich Eindruck bei Einsteigern, aber irgendwann merkt man, dass viele Dinge nicht so funktionieren wie man es sich wünscht.
Jedoch ganz ohne Automatismen kann und will man nicht immer auskommen. Ich finde es gut, dass meine Programmiersprache sich um den Speicher kümmert, weil der Aufwand sich darum zu kümmern wohl eher geringen nutzen hätte. Auch finde ich es angenehm, mit den Daten als Objekte arbeiten zu können, auch wenn diese Daten letztendlich nur Spalten in einem RDBMS sind. Ich habe mich letztens darüber unterhalten, dass es praktische wäre, Daten in Webapplikationen direkt als Objekte serialisieren zu können - klar, das fühlt sich sauberer an, aber ein ORM reicht Momentan auch aus, weil es eben so Dinge wie Interaktion mit dem DBMS automatisiert.
gerold hat geschrieben:Alles was ich jetzt will, ist ein Framework, das mir nur die wichtigsten Dinge wie Auslieferung der HTML-Seiten, Auslieferung der statischen Objekte, Sessions, Authentifizierung und noch vielleicht ein paar Kleinigkeiten erledigt. Alles was darüber hinaus geht, möchte ich gezielt nachinstallieren und vorher auswählen/testen können.
Ich glaube diese Größenordnung ist in WSGI-Frameworks nicht vertreten, bzw. nicht besonders gut. Es gibt Colubrid und Werkzeug die Seiten ausliefern (d.h. Request+Response), für Auslieferung der Statischen Inhalte gibt es WSGI-Anwendungen (namentlich `static`), dür Sessions (`Beaker`, `flup`, `web`, `Web Modules`, `wsgistate`, `WSGIUtils`) & Auth (`AuthKit`, `paste.auth`, `Barrel`, `web`, `Web Modules`, `wsgiauth`, `WSGIUtils`) gibt es Middlewares. Es ist ja alles da, vieles sogar mehrfach implementiert.
gerold hat geschrieben:Um zu Django zurück zu kommen. (Gleiches gilt für Pylons.) Im Moment bin ich nicht in der Stimmung für eine Eierlegende Wollmilchsau, die ich zuerst auf Diät setzen muss, bevor sie für mich verwendbar wird. Wie du siehst ist das auch wieder nur eine Gefühlssache. Wie vieles bei mir.
Für DJango trifft das zu - wenn du das nimmst, was es bietet ist es super. Willst du etwas anderes, wird es kompliziert. Das ist eben das Argument für Pylons: Pylons ist stark in WSGI integriert und kann so problemlos WSGI-Komponenten nutzen. Und wenn du Pylons nicht mehr magst, dann wirst du es los, kannst die Komponenten aber weiterhin verwenden.
gerold hat geschrieben:Zwei Frameworks werde ich mir ganz sicher noch ansehen: Webware und Werkzeug.
Ich habe mir Webware vor langer Zeit, also 2003, also 0.8.1 aktuell war angesehen (da war ich noch auf dem PSP-Trip, bevor ich festgestellt habe, dass das nicht der Weg ist, den es sich zu gehen lohnt). Das war bevor sich WSGI Webware von Webware abgespalten hat, also das was später WSGIKit wurde und nun Paste ist. Es kam mir damals kompliziert zu installieren vor und wenig benutzt. Ein Framework das nur wenige nutzen ist meiner Meinung weniger Wert als ein Framework, dass nur ich nutze, weil ich es selbst zusammengestellt habe. Andernfalls muss ich mit den Entscheidungen der Framework-Entwickler leben und bekomme kaum Support.
