Hallo,
ich suche eine möglichst kompakte WSGI-Bibliothek bzw. ein Mini-Framework, das URLs weitgehend frei konfigurierbar auf Objekte bzw. Methoden abbilden kann. Ich suche kein umfassendes Framework à la Django oder Pylons, denn ich entwickle gerade eine leichte Framework-Allergie.
Im Forum wird gerne Werkzeug genannt und ich habe mir auch die Website dazu angesehen. Sieht auch prinzipiell nicht schlecht aus, aber irgendwie finde ich es "unzugänglich". Ich verstehe es nicht so richtig. CherryPy erscheint mir da einfacher und bringt auch gleich noch ein paar nette Sachen wie Sitzungsverwaltung mit. Aber soweit ich CherryPy bisher verstanden habe, kann ich die URLs nicht so frei konfigurieren, wie ich das gerne möchte.
Ich will URLs nach folgendem Muster haben http://sitexy.com/Seite1 und http://sitexy.com/page/save?id=12333 Bei ersterem soll die Standard-Aktion des Standard-Controllers aufgerufen werden und bei letzterem soll die Methode "save" im Controller "page" aufgerufen und ihr der Parameter "id=12333" übergeben werden.
Wie könnte ich dieses Ziel möglichst einfach und elegant erreichen?
URLs auf Controller abbilden
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Hast Du denn mal damit herumgespielt? Man kann das Routing-System ja ganz simpel in einer Shell testen.deamon hat geschrieben: Im Forum wird gerne Werkzeug genannt und ich habe mir auch die Website dazu angesehen. Sieht auch prinzipiell nicht schlecht aus, aber irgendwie finde ich es "unzugänglich". Ich verstehe es nicht so richtig.
Hier noch mal die Doku fürs Routing:
http://werkzeug.pocoo.org/documentation/routing
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Wenn du Werkzeugs Routing nicht magst, dann kannst du dir ja Routes ansehen, dass soweit ich weiß in der Pylons-Welt recht populär ist.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Die URL-Abbildung von Werkzeug wäre meine kleinste Sorge. Mein Problem ist Werkzeug selbst. Das ist mir irgendwie zu "low level" und zu weit von der praktischen Anwendung entfernt.
Da gefällt mir CherryPy besser, wo man ruckzuck sein erstes Beispiel zum Laufen bekommt. Mittlerweile habe ich auch herausgefunden, dass man CherryPy auch mit Routes verwenden kann, aber so ganz wie ich mir das vorstelle, klappte das auch nicht - kann an meinem mangelnden Verständnis liegen. In der CherryPy-Doku wurde auch erwähnt, dass man sich seinen eigenen Mechanismus zur Abbildung schreiben könnte. Nur welche Schnittstelle dabei erforderlich ist, stand dort nicht. Wie ich es hasse, wenn dank Duck-Typing Schnittstellen nicht mehr explizit beschrieben werden! Aber das ist ein anderes Thema ...
Da gefällt mir CherryPy besser, wo man ruckzuck sein erstes Beispiel zum Laufen bekommt. Mittlerweile habe ich auch herausgefunden, dass man CherryPy auch mit Routes verwenden kann, aber so ganz wie ich mir das vorstelle, klappte das auch nicht - kann an meinem mangelnden Verständnis liegen. In der CherryPy-Doku wurde auch erwähnt, dass man sich seinen eigenen Mechanismus zur Abbildung schreiben könnte. Nur welche Schnittstelle dabei erforderlich ist, stand dort nicht. Wie ich es hasse, wenn dank Duck-Typing Schnittstellen nicht mehr explizit beschrieben werden! Aber das ist ein anderes Thema ...
Kennst du KISS (nein, nicht die Band)? Genau das ist Werkzeug. Ich habe das Gefühl, dass du noch gar nicht genau weißt, was du eigentlich willst. Experimentiere einfach mit beiden Frameworks ein wenig herum, bis du dich entschieden hast.
Werkzeug ist ja auch kein vollständiges Framework, sondern "one of the most advanced WSGI utility modules." Es ist mit Absicht low-level.deamon hat geschrieben:Die URL-Abbildung von Werkzeug wäre meine kleinste Sorge. Mein Problem ist Werkzeug selbst. Das ist mir irgendwie zu "low level" und zu weit von der praktischen Anwendung entfernt.
Vielleicht hättest du doch bei Java bleiben sollen ...Wie ich es hasse, wenn dank Duck-Typing Schnittstellen nicht mehr explizit beschrieben werden!
In der Tat.Aber das ist ein anderes Thema ...
@Leonidas
Naja, populär? Es ist halt der Standard. Viel halte ich davon allerdings nicht, im Vergleich zu Werkzeug oder regulären Ausdrücken ist es schon sehr beschränkt.
Um Missverständnissen vorzubeugen: ich finde Duck-Typing in vielen Fällen sehr elegant. Mir gefällt nur nicht, dass viele Python-Entwickler meinen, die Schnittstelle müsste dann nicht mehr dokumentiert werden. Python verlangt dem Entwickler Disziplin ab, wenn es ihn nicht zwingt, Schnittstellen explizit zu beschreiben. In der Tat ist die explizite Beschreibung von Schnittstellen ein Punkt, der mir in Java gefällt. Wie schön und sauber man bei Spring alles zusammenstöpseln kann ist fantastisch. Ich kenne wenig Frameworks, die so sauber und so flexibel sind.lunar hat geschrieben:Vielleicht hättest du doch bei Java bleiben sollen ...Wie ich es hasse, wenn dank Duck-Typing Schnittstellen nicht mehr explizit beschrieben werden!
Trotzdem mag ich auch Python - nur halt aus anderen Gründen als Java.
So einigermaßen weiß ich schon, was ich will, ich bin nur nicht festgelegt. Meine Idealvorstellung wäre eine Bibliothek die etwa das bietet, wie bei Java das Servlet-API. Mir erscheint das Servlet-API wesentlich komfortabler in der Benutzer als Werkzeug und erst recht als WSGI pur. Dazu hätte ich dann gerne noch eine Implementierung, sprich einen kleinen Webserver für die Entwicklungsphase. Vielleicht sollte man beides Zusammen als Mini-Web-Framework bezeichnen.derdon hat geschrieben: Ich habe das Gefühl, dass du noch gar nicht genau weißt, was du eigentlich willst.
CherryPy ist schon ziemlich nah dran, aber die Schnittstellen sind leider nirgends beschrieben. Es steht dort, dass man sich seinen eigenen Dispatcher schreiben könnte, aber wie der aussehen muss, damit Python ihn am Gang und Quaken als Dispatcher-Ente erkennt, steht nirgends.
Abgesehen, dass es das alles schon gibt und nur unter der Annahme, man wolle es selbst machen, ist ein einfacher Dispatch basierend auf URL-Segmenten doch auch kein Hexenwerk:
Parameter werden in den gängigen Rahmenwerken ja schon herausgezogen und stehen dann als Dict zur Verfügung. Das könnte man dann ja noch mit `**params` mit in den Aufruf der Methode des Controllers (bei mir `view` genannt) reinreichen. Bei Rails ist das wohl so, dass der optionale dritte Wert (bei mir `obj`) automatisch zu einem "id"-Parameter wird.
Stefan
Code: Alles auswählen
def cap(s):
return "".join(t.capitalize() for t in s.split("_"))
def route(path):
segments = path.strip("/").split("/", 2)
controller = cap(segments[0]) + "Controller"
view = segments[1] if len(segments) > 1 else "index"
obj = segments[2] if len(segments) > 2 else None
print "%s().%s(%s)" % (controller, view, obj)
route("/foobar/")
route("/foobar/show")
route("/bar/show/1")
Stefan