I'm not intimately familiar with the Model objects, I just mocked them up. I also didn't cover every corner case translating the URL's to the graph, but I'm sure you have tests for those already.
nice!
Posted bychrismat
2008-07-21 11:10 PM
Very instructive, thank you! The model graph is spot-on for an example.
There are a few minor differences between this and what repoze.bfg's traverser does:
- The "controller" (view, page handler, whatever) receives the "context" and the "request" as arguments in bfg
instead of the subpath and kwargs from the request. This could be done in your example by returning
a "controller" from find_handler as something that, when called, just turned around and called the "real"
controller with those arguments (as we have access to both within find_handler).
- The subpath is attached to the request we pass. We don't attempt to map kwargs into view args in repoze.bfg.
The interface lookup stuff is just a detail, really, your example is in the right spirit.
I wonder how far I could get just using CP to do the job. Here are some further nice-to-haves:
- A WebOb request object (just because WSGI is sort of our meme).
- An ability to return a WebOb Response object from the "controller" instead of a string
response (because the explicitness makes the response handling machinery a bit
simple, and for the above reason).
I've created a repoze.bfg branch for experimentation with CherryPy at http://svn.repoze.org/repoze.bfg/branches/cherrypy-branch/ .
I've not done anything meaningful in there so far except change setup.py to rely on CherryPy and to put CherryPy 3.1.0 in our index. I hope to find a little time to hack together a version of our "router" in there that relies on a modified version of your sample dispatcher.
I'm not intimately familiar with the Model objects, I just mocked them up. I also didn't cover every corner case translating the URL's to the graph, but I'm sure you have tests for those already.
There are a few minor differences between this and what repoze.bfg's traverser does:
- The "controller" (view, page handler, whatever) receives the "context" and the "request" as arguments in bfg
instead of the subpath and kwargs from the request. This could be done in your example by returning
a "controller" from find_handler as something that, when called, just turned around and called the "real"
controller with those arguments (as we have access to both within find_handler).
- The subpath is attached to the request we pass. We don't attempt to map kwargs into view args in repoze.bfg.
The interface lookup stuff is just a detail, really, your example is in the right spirit.
I wonder how far I could get just using CP to do the job. Here are some further nice-to-haves:
- A WebOb request object (just because WSGI is sort of our meme).
- An ability to return a WebOb Response object from the "controller" instead of a string
response (because the explicitness makes the response handling machinery a bit
simple, and for the above reason).
Thanks a lot for the example!
Replies to this comment
I've not done anything meaningful in there so far except change setup.py to rely on CherryPy and to put CherryPy 3.1.0 in our index. I hope to find a little time to hack together a version of our "router" in there that relies on a modified version of your sample dispatcher.