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).
Thanks a lot for the example!
Nice to haves...
Posted byfumanchuat
2008-07-22 12:06 PM
- A WebOb request object (just because WSGI is sort of our meme).
You could certainly grab such a thing out of the WSGI environ, but I'm not sure what that would buy you. The CP spec only requires cherrypy.request.handler to be a callable object, so the rest is up to you.
- 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).
As long as it's iterable, that shouldn't be a problem. CP calls: "cherrypy.response.body = handler()", and the Body descriptor class only munges the output if isinstance (output, (basestring, types.FileType, None)).
However, if you're buffering output (the default), then Response.finalize will call newbody = ''.join([chunk for chunk in self.body]). It might just be easiest to wrap whatever CP outputs in a new WebOb response instance if you really need one of those.
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!
You could certainly grab such a thing out of the WSGI environ, but I'm not sure what that would buy you. The CP spec only requires cherrypy.request.handler to be a callable object, so the rest is up to you.
- 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).
As long as it's iterable, that shouldn't be a problem. CP calls: "cherrypy.response.body = handler()", and the Body descriptor class only munges the output if isinstance (output, (basestring, types.FileType, None)).
However, if you're buffering output (the default), then Response.finalize will call newbody = ''.join([chunk for chunk in self.body]). It might just be easiest to wrap whatever CP outputs in a new WebOb response instance if you really need one of those.