URLs auf Controller abbilden

[deamon]

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?

[Hyperion]

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.

Hast Du denn mal damit herumgespielt? Man kann das Routing-System ja ganz simpel in einer Shell testen.

Hier noch mal die Doku fürs Routing:
http://werkzeug.pocoo.org/documentation/routing

[nemomuk]

Das kriegst du mit Werkzeug wunderbar hin. Schau dir einfach mal das Einsteiger-Tutorial an. Das kannst du auf verschiedene Art und Weise lösen - das ist ja das schöne an Werkzeug...

[Leonidas]

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.

[deamon]

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

[derdon]

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.

[lunar]

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.

Werkzeug ist ja auch kein vollständiges Framework, sondern "one of the most advanced WSGI utility modules." Es ist mit Absicht low-level.

Wie ich es hasse, wenn dank Duck-Typing Schnittstellen nicht mehr explizit beschrieben werden!

Vielleicht hättest du doch bei Java bleiben sollen ...

Aber das ist ein anderes Thema ...

In der Tat.

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

[deamon]

Wie ich es hasse, wenn dank Duck-Typing Schnittstellen nicht mehr explizit beschrieben werden!

Vielleicht hättest du doch bei Java bleiben sollen ...

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.

Trotzdem mag ich auch Python - nur halt aus anderen Gründen als Java.

[deamon]

Ich habe das Gefühl, dass du noch gar nicht genau weißt, was du eigentlich willst.

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.

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.

[sma]

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:

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

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