Werkzeug vs. Colubrid

[monocult]

Hallo,

Ich habe bisher Colubrid verwendet. Nun ist es ja so das wenn ich das richtig verstehe Werkzeug der Nachfolger werden soll. Daher habe ich mir das Werkzeug mal angeschaut. Für mich wirkt es auf den ersten blick komplizierter bzw. sind die Funktionen weniger abstrahiert.

Es stellt sich daher die Frage was bei neuen Projekten verwenden. Werkzeug soll ja einige Design Fehler in Colubrid schlissen. Vielleicht kann mich ja mal jemand aufklären welche das sind und was das für mich als User bedeutet.

Eine andere Frage währe wird mit Abschluss von Werkzeug die Colubrid Entwicklung eingestellt? Wo liegen sonst die Unterschiede?

bitte klärt mich auf

[EnTeQuAk]

Das kann ich dann mal versuchen (Armin, bei Fehlinfos bitte verbessern ).

Colubrid war der erste WSGI-Handler, der wie du schon sagtest einige Design-Fehler hat. Der Fehler liegt daran, das Colubrid im Prinziep nur "Applications" kennt also genauer gesagt ein großer Brocken ist. Werkzeug dagegen bietet nur verschiedene Module unter einer Oberfläche zum erstellen von WSGI-Applikationen.

Eine andere Frage währe wird mit Abschluss von Werkzeug die Colubrid Entwicklung eingestellt? Wo liegen sonst die Unterschiede?

Hier kann ich dich beruhigen. mitsuhiko hat geplant, Colubrid auf Werkzeug basis weiterlaufen zu lassen und ich bin dabei das umzusetzen. (aktuell etwas langsam, aber demnächst könnte es fertig werden)
Was bedeutet, das du funktionierende Colubrid-Anwendungen weiternutzen können wirst, jedoch mit Werkzeug als Abhängigkeit. Werkzeug wird dann unter 'colubrid._werkzeug' erreichbar gemacht. So ist es geplant, sodass eben bestehende Applikationen weiterlaufen können und wir eine einheitliche Code-Basis haben.

Grundlegend würde ich persönlich Werkzeug als Basis für Neuentwicklungen nehmen, wenn du nicht auf Colubrids' fertige Applikationen angewiesen bist. Mit dem 'kickstart' und 'contrib' Modulen gibts dort auch sehr gute, umfangreiche fertige Dinge die man benutzen kann um schnelle Ergebnisse zu erziehlen. Und das Werkzeugs' Routing einfach erste Sahne ist, find ich sowieso

Colubrid wird von Werkzeug profitieren, aber nur für die Kompatibilität zu älteren Anwendungen weitergeführt.

MfG EnTeQuAk

[monocult]

ok, das heißt aber auch das so Sachen wie z.B. WebpyApplication in Colubrid nicht unter Werkzeug zur Verfügung stehen sonder dann selber geschrieben werden müssen(wie in dem Beispiel unter examples).

Hast du ein Beispiel für Kickstart? Mit werkzeug-bootstrap kommt man ja auch sehr schnell zu einem Anfang.

Überhaupt fehlt es verständlicher weise noch an Doku.

Das was ich bisher verstanden habe ist allerdings sehr sympathisch


edit:

wobei ich gerade feststelle das werkzeug-bootstrap nach einem update nicht mehr geht.

[EnTeQuAk]

Mit "Kickstart" meine ich dieses Modul. Das wird sich sicherlich noch etwas füllen, im Moment ist halt nur ein kleines Template-Interface auf Basis der Werkzeug-Template-Engine und die basis Request/Response Klassen definiert.

ok, das heißt aber auch das so Sachen wie z.B. WebpyApplication in Colubrid nicht unter Werkzeug zur Verfügung stehen sonder dann selber geschrieben werden müssen(wie in dem Beispiel unter examples).

Exakt.

wobei ich gerade feststelle das werkzeug-bootstrap nach einem update nicht mehr geht.

In wieweit, es funktioniert nicht? Im Allgemeinen, wurde überlegt obs überhaupt derart gebraucht wird. Aber dazu weiß ich grad nichts genaueres.


MfG EnTeQuAk

[Leonidas]

Mit "Kickstart" meine ich dieses Modul. Das wird sich sicherlich noch etwas füllen, im Moment ist halt nur ein kleines Template-Interface auf Basis der Werkzeug-Template-Engine und die basis Request/Response Klassen definiert.

Richtig. Ich habe da noch ein paar andere Dinge geplant, aber in den nächsten Monaten keine Zeit das richtig aus meinem Projekt auszugliedern. Aber es freut mich dass das `Kickstart`-Modul Anklang findet Für die Zukunft ist plane ich, da noch einige weitere angenehme Shortcuts hinzuzufügen, vielleicht etwas Integration für Serialisierungsmethoden (wobei ich da nicht ganz sicher bin ob das wirklich sinnvoll ist) und Template-Systeme. Die Zukunft wird zeigen, wie das letztendlich wird, nur habe ich die nächsten paar Monate nicht genug Zeit dafür. Muss mal gucken, dass das ins nächste Release dann einfließt.

[keppla]

Werkzeug, ganz klar!
WSGI, wie es in meinen Augen sein sollte. Nur das, was man will, nichts, was im Weg rumsteht.
Auch wenn ich noch etwas schwierigkeiten mit dem Routing habe, bis jetzt das coolste, was ich gesehen hab.

[monocult]

In wieweit, es funktioniert nicht? Im Allgemeinen, wurde überlegt obs überhaupt derart gebraucht wird. Aber dazu weiß ich grad nichts genaueres.

naja der Server startet nicht. sieht aber auch aus als währe da gerade was dran geändert worden.

prinzipiell finde ich das ein nettes Gadget. gerade um einen einstieg zu haben bzw. z.B. in Tutorals einen schnelle Ausgangs Basis zu generieren.

Klar kann man sich solche Templates auch selbst anlegen und cp. Aber so finde ich das schon ganz nett.

es darf nur nicht so ausarten wie bei manchen Frameworks. Wo man mehr Shell Kommandos im Kopf haben muss als alles andere.

[keppla]

es darf nur nicht so ausarten wie bei manchen Frameworks. Wo man mehr Shell Kommandos im Kopf haben muss als alles andere.

Oh ja. Codegeneration ist in meinen Augen unpythonisch. Sie macht das "Schreiben" von viel Code einfacher, ohne das Lesen zu vereinfachen.

[monocult]

wie sieht den der Entwicklungsstand von Werkzeug im Allgemeinen aus?

[mitsuhiko]

wie sieht den der Entwicklungsstand von Werkzeug im Allgemeinen aus?

Wir sind zufrieden Es geht voran und Werkzeug kümmert sich in der Zwischenzeit auch schon um nervige Dinge des HTTP Standards (zb Conditional Responses, automatisches "absolutisieren" von Redirect Zielen, etags, accept-* Parsing on noch so ein paar Dingen)
Die Mini Template Engine ist jetzt ganz gut debugbar, wenn man die Templates von Dateien läd.

Was das bootstrap Skript angeht: Irgendwie hat sich rauskristalisiert, dass es wesentlich angenehmer ist, wenn man erst gar keine Code Generation für eine einfache Anwendung braucht. Wo man am Beginn der Werkzeug Entwicklung noch nicht mit weniger als 100 Zeilen Code weggekommen ist, sinds jetzt Dank kickstart und verbesserungen an Werkzeug selbst um die 30 Zeilen. Und da ist jetzt dann auch ein leicht erweiterbares Manager-Script dabei

Also Plan momentan ist es die einzelnen Komponenten weiter zu dokumentieren, mehr Unittests zu schreiben und werkzeug-bootstrap fallen zu lassen.

[monocult]

seit ich mir heute Mittag eine neue Version gezogen habe geht garnix.
bei allen examples die selbe Meldung.

werde morgen nochmal in ruhe drüber schauen.

Code: Alles auswählen

* Running on http://localhost:5000/
Traceback (most recent call last):
  File "wsgiref/handlers.py", line 92, in run
  File "upload.py", line 42, in application
    resp = upload_file(req)
  File "upload.py", line 34, in upload_file
    ''', mimetype='text/html')
  File "/usr/lib/python2.5/site-packages/Werkzeug-0.1dev-py2.5.egg/werkzeug/wrappers.py", line 342, in __init__
    if conditional_request is None:
UnboundLocalError: local variable 'conditional_request' referenced before assignment
localhost - - [29/Nov/2007 18:04:53] "GET / HTTP/1.1" 500 59

[mitsuhiko]

hg pull -u. Da ist wohl unabsichtlich debug Code reingekommen.

[Y0Gi]

Ich denke ebenfalls, dass der Bootstrapping-Kram zuviel des Guten ist, da man bereits mit sehr wenigen Zeilen Code das minimale Grundgerüst einer Applikation zusammen bekommt - und bei Werkzeug geht es ja schließlich darum, ein schlankes, minimales Gerüst als Basis anzubieten, und (u.a.) genau damit punktet es ja überhaupt gegen Paste (und auch Colubrid).