SQLAlchemy + Threads

[gerold]

Wo liegt da also nun der große Unterschied frag ich mich gerade? (Denn Werkzeug war dem OP ja irgend wie zu "wenig" Framework)

Hallo Hyperion!

Ich schieße jetzt einfach mal in die Luft: Werkzeug ist, meiner Meinung nach, nicht so einfach zu benutzen wie CherryPy. Allein wenn ich mir das erste Beispiel anschaue, welches man auf diser Seite http://werkzeug.pocoo.org/ findet, fällt mir auf, dass CherryPy für mich einfacher zu benutzen ist.
CherryPy kümmert sich um die Sessionverwaltung, die Base-Authentifizierung, die Digest-Authentifizierung und um das Handling von abschließenden Slashes (/). Es stellt mir eine Konfigurationsumgebung zur Verfügung, mit welcher ich über eine INI-Datei oder selber über den Quellcode, Einstellungen verwalten kann. Weiters läuft CherryPy ohne großes Zutun mit mod_python und mod_wsgi. Es läuft aber auch als eigenständiger Server z.B. hinter einem Apachen mit mod_proxy.
Requests werden in einfach zu verwendende "cherrypy.request"-Objekte umgewandelt. Parameter (POST, GET,...), werden direkt als Parameter an die Funktion übergeben und können somit sehr einfach verwendet werden.
Von haus aus, wird eine sehr einfach gehaltene Strukturierung der URL über Klasseninstanzen vewendet. Wenn man, wie Jan.O, eine andere URL-Struktur haben möchte, dann kann man sich selber einen URL-Dispatcher schreiben und einbinden. Man kann aber auch bereits fertige Dispatcher einbinden. Usw...

Ich möchte keinen Streit lostreten. Mir persönlich gefällt die Art nicht, wie man mit Werkzeug arbeiten muss. Das ist aber nur eine persönliche Meinung und ich möchte niemanden beleidigen, der gerne mit Werkzeug arbeitet. Werkzeug ist sicher kein schlechtes Tool.

mfg
Gerold

[Leonidas]

Werkzeug nimmt dem Programmierer wenig bis gar nichts ab, während CherryPy zumindest Sessionverwaltung, Routing und iirc auch Authentifizierung weitgehend automatisch kann.

Ja ok, ich bezog mich grad auf das Routing, welches Werkzeug ebenso bietet (oder sehe ich das falsch?) - aber das andere sind da sicherlich Argumente für CherryPy. Da müßte man bei werkzeug ja wirklich noch Hand anlegen.

Werkzeug bietet ein Routing - ja, ebenso wie es auch noch andere Kleinigkeiten wie Securecookie und einige Datentypen die für Web-Arbeit nützlich sind. Aber du kannst es dir eher wie ``bsdutils`` vorstellen: eher ein Paket mit nützlichen Programmen die kleine Aufgaben erledigen. Niemand würde wohl auf die Idee kommen, alleine mit Werkzeug irgendeine Webapplikation zu bauen - dafür gibt es bereits genug WSGI-Tools, als das man das noch einmal implementieren müsste.

CherryPy macht hingegen etwas mehr Vorgaben (damit meine ich die Standardeinstellungen). Einige bevorzugen eher die Vorgaben (CherryPy, Django) und andere geben der Freiheit den Vorzug (Werkzeug). Hängt auch in irgendwieweit ab, was man genau implementieren will.

Edit: Pylons aus Auflistung entfernt, danke Lunar.

[Hyperion]

@Leonidas & Gerodl: Danke für den kurzen "Vergleich". Ich muss mir wohl auch mal CherryPy angucken denke ich

[lunar]

@Leonidas
pylons macht ebenfalls viele Vorgaben. Die Verzeichnisstruktur des Quellcodes ist vorgegeben, der Datenbankzugriff, das Routing, die Sessions, etc. Man kann es nur sehr, sehr leicht austauschen.

[Jan.O]

Damit kannst du die oben genannten URLs verwenden.
http://paste.pocoo.org/show/113472/

Und wie komme ich jetzt an die POST-Daten ran? xD

[gerold]

Und wie komme ich jetzt an die POST-Daten ran? xD

Hallo Jan.O!

Diese werden (automatisch) als Parameter an die aufgerufene Funktion übergeben. Gleich, wie in diesem Beispiel http://www.python-forum.de/post-132756.html#132756 die Funktion "showformdata".

Und mit ``cherrypy.request.method`` bekommst du raus, ob die Anfrage per POST oder GET rein gekommen ist.

mfg
Gerold

[Jan.O]

Und wie komme ich jetzt an die POST-Daten ran? xD

Hallo Jan.O!

Diese werden (automatisch) als Parameter an die aufgerufene Funktion übergeben. Gleich, wie in diesem Beispiel http://www.python-forum.de/post-132756.html#132756 die Funktion "showformdata".

Und mit ``cherrypy.request.method`` bekommst du raus, ob die Anfrage per POST oder GET rein gekommen ist.

mfg
Gerold

Oh, stimmt! Hätte gedacht, dass dies wegen Routes nicht der fall ist. Naja, man hätte eigentlich erwarten können, dass es trotzdem noch funktioniert. Dann werde ich jetzt einfach **args oder **POST als argument von post-methoden benutzen, und habe direkt ein dictionary mit allen parametern.

Danke noch mal

EDIT: habe das ursprüngliche Problem dieses threads übrigens gelöst. war zu blöd um zu erkennen, dass scoped_session eine KLASSE erzeugt, welche sich autmatisch mit der DB verbindet. Diese klasse kann man dann erzeugen wo man will.