Werkzeug vs. Colubrid

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum

Werkzeug vs. Colubrid

Werkzeug
8
89%
Colubrid
1
11%
 
Abstimmungen insgesamt: 9
monocult
User
Beiträge: 37
Registriert: Donnerstag 31. März 2005, 09:55
Wohnort: hennef
Kontaktdaten:

Werkzeug vs. Colubrid

Beitragvon monocult » Donnerstag 29. November 2007, 10:57

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
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:

Beitragvon EnTeQuAk » Donnerstag 29. November 2007, 12:24

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
User
Beiträge: 37
Registriert: Donnerstag 31. März 2005, 09:55
Wohnort: hennef
Kontaktdaten:

Beitragvon monocult » Donnerstag 29. November 2007, 12:43

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
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:

Beitragvon EnTeQuAk » Donnerstag 29. November 2007, 13:38

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
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Donnerstag 29. November 2007, 13:57

EnTeQuAk hat geschrieben: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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
keppla
User
Beiträge: 483
Registriert: Montag 31. Oktober 2005, 00:12

Beitragvon keppla » Donnerstag 29. November 2007, 14:02

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
User
Beiträge: 37
Registriert: Donnerstag 31. März 2005, 09:55
Wohnort: hennef
Kontaktdaten:

Beitragvon monocult » Donnerstag 29. November 2007, 14:09

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.
Benutzeravatar
keppla
User
Beiträge: 483
Registriert: Montag 31. Oktober 2005, 00:12

Beitragvon keppla » Donnerstag 29. November 2007, 16:10

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
User
Beiträge: 37
Registriert: Donnerstag 31. März 2005, 09:55
Wohnort: hennef
Kontaktdaten:

Beitragvon monocult » Donnerstag 29. November 2007, 16:25

wie sieht den der Entwicklungsstand von Werkzeug im Allgemeinen aus?
Benutzeravatar
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Beitragvon mitsuhiko » Donnerstag 29. November 2007, 17:19

monocult hat geschrieben: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.
TUFKAB – the user formerly known as blackbird
monocult
User
Beiträge: 37
Registriert: Donnerstag 31. März 2005, 09:55
Wohnort: hennef
Kontaktdaten:

Beitragvon monocult » Donnerstag 29. November 2007, 18:08

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=]
* 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
[/code]
Benutzeravatar
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Beitragvon mitsuhiko » Donnerstag 29. November 2007, 18:12

hg pull -u. Da ist wohl unabsichtlich debug Code reingekommen.
TUFKAB – the user formerly known as blackbird
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Beitragvon Y0Gi » Donnerstag 29. November 2007, 21:28

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

Wer ist online?

Mitglieder in diesem Forum: Google [Bot]