SQLObject und Pylons

[Lutz]

Hi,

Pylons behauptet ja, dass es mit jedem ORM kann. Leider hab ich keine brauchbare Doku gefunden wie ich das aktuelle Pylons mit SQLObject einsetzen kann.

Hintergrund: ich würde gerne meine bestehende App auf Pylons migrieren und dabei erstmal das bestehende DB Model, basierend auf SQLObject, bei behalten.

Hat jemand eventuell einen Tipp/URL wo ich entsprechende Infos finden kann ?

Danke.

Lutz

[Leonidas]

Im großen und ganzen wird sich das seit dem hier wohl nicht so stark geändert haben, nehme ich an.

[sma]

Vielleicht solltest du dir ansonsten ein besser dokumentiertes Webrahmenwerk suchen ;) Wenn ich das Konzept von Pylons richtig verstanden habe, ist doch nicht nur egal, welchen ORM man mit Pylons benutzt, sondern auch, welches Webrahmenwerk... ich meine, was bietet einem Pylons gegenüber dem Ansatz, selbst ORM, Templatesystem und URL-Dispatcher zu kombinieren. Noch enthalten zu sein scheint ein Code-Generator, aber so eine Komponente macht mich eh misstrauisch, da es iA nie gut ist, irgendwelche Code über irgendwelche Mauern zu schmeißen.

Somit hilft dir vielleicht auch Werkzeug, Yaro oder WebOb als dünne Schicht über dem WSGI-Protokoll. Letztlich musst du "doch nur" das Problem lösen, wie du pro Request effizient eine Session anlegen und verwalten kannst. Der Mann von Yaro hat mit Rip ein weiteres Projekt, das in einem Tutorial den Umgang mit SqlObject zeigt. Bei Werkzeug habe ich nur ein Beispiel für SqlAlchemy gesehen und für WebOb hat Google auf die Schnelle nichts ausgespuckt.

Stefan

[Lutz]

Vielleicht solltest du dir ansonsten ein besser dokumentiertes Webrahmenwerk suchen Wenn ich das Konzept von Pylons richtig verstanden habe, ist doch nicht nur egal, welchen ORM man mit Pylons benutzt, sondern auch, welches Webrahmenwerk... ich meine, was bietet einem Pylons gegenüber dem Ansatz, selbst ORM, Templatesystem und URL-Dispatcher zu kombinieren. Noch enthalten zu sein scheint ein Code-Generator, aber so eine Komponente macht mich eh misstrauisch, da es iA nie gut ist, irgendwelche Code über irgendwelche Mauern zu schmeißen.

Da geb ich dir recht. Pylons bot die Möglichkeit des schnellen Zuganges mit erstmal flacher Lernkurve bezüglich Pylons.

Somit hilft dir vielleicht auch Werkzeug, Yaro oder WebOb als dünne Schicht über dem WSGI-Protokoll. Letztlich musst du "doch nur" das Problem lösen, wie du pro Request effizient eine Session anlegen und verwalten kannst. Der Mann von Yaro hat mit Rip ein weiteres Projekt, das in einem Tutorial den Umgang mit SqlObject zeigt. Bei Werkzeug habe ich nur ein Beispiel für SqlAlchemy gesehen und für WebOb hat Google auf die Schnelle nichts ausgespuckt.

Yaro hab ich mir angeschaut, sah auch erstmal nett aus, mag wohl nur meine Version von flup nicht und mault irgend was rum.

Ich habe mich dann mit Werkezug beschäftigt. Auf den ersten Blick wirkt es erstmal viel komplizierter als Pylons oder gar Django. Zumindest ging es mir so. Ich hab dann das coolmagic Beispiel im example Ordner gefunden. Das implementiert etwas in der Art eines MV(C)T. Allerdings auf eine etwas brauchbarere Art für mich als es das Tutorial tut. Im Gengensatz zum Tut kommen hier beliebig viele Views zum Einsatz, was besser für größere Anwendungen passt.

Ich muss jetzt noch bißchen mit Werkzeug rumspielen und heraus finden wie ich zu sowas wie Sessions komme und wie ich die Sache mit SQLObject verbinde. Schließlich sollen ja bestehende Modelle verwendet werden. Ich mag die nicht erst nach SQLAlchemy portieren auch wenn das jetzt wohl state of the art ist.

Hat vielleicht jemand einen Tipp wo ich die Datenbankverbindung für SQLObject zentral anlegen kann ?
Optimal wäre natürlich wenn dabei Connectionpooling zum Einsatz käme.

Wie siehts mit einem SessionTool aus ?
Gibts was das mit postgresql arbeitet und vielleicht sogar auch Session auf URL-Bassis kann ?
Nicht immer sind Cookies möglich oder führen zu Problemen.

Lutz

PS: phpBB scheint Probleme mit wechselnden IPs zu haben. Da ich über eine redundante Verbindung mit zwei DSL-Anschlüssen ins Netz gehe, verlangt phpBB immer mal wieder eine Neuanmeldung.