[Repoze-dev] custom Request and Response classes in repoze.bfg
hey all, so in building my first repoze.bfg app, it's occurred to me that i'd like to use a custom Request and Response classes, just simple subclasses of the WebOb defaults so that i can set configurable class variables like default_charset. unless i'm missing something in the code, there's currently no support for this. how would folks feel about the following changes: - in repoze.bfg.router, the paster config would be checked for request_class setting, which would be a dotted path to a request class to use. absence of this setting means use the default class, nothing changes. - every place that a response object is currently instantiated, use request.ResponseClass instead of explicitly using the WebOb class. AFAICT, response objects are instantiated in the following repoze.bfg modules: - chameleon_[genshi|text|zpt] - view - wsgi - xslt in the 'view' and 'wsgi' modules, we're already holding the request object when the response is instantiated, so there's very little to change. in all of the other modules, the response is being instantiated in a render_[template|transform]_to_response function. the biggest change, then, would be to have all of the render-to-response methods start requiring request objects as arguments. this could be optional at first, w/ a deprecation warning if it's left out, until such time as we might see fit to force the issue. whaddayareckon? -r ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] custom Request and Response classes in repoze.bfg
2009/1/14 Rob Miller r...@burningman.com: so in building my first repoze.bfg app, it's occurred to me that i'd like to use a custom Request and Response classes, just simple subclasses of the WebOb defaults so that i can set configurable class variables like default_charset. unless i'm missing something in the code, there's currently no support for this. You do have the INewRequest event. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] custom Request and Response classes in repoze.bfg
Malthe Borch wrote: 2009/1/14 Rob Miller r...@burningman.com: so in building my first repoze.bfg app, it's occurred to me that i'd like to use a custom Request and Response classes, just simple subclasses of the WebOb defaults so that i can set configurable class variables like default_charset. unless i'm missing something in the code, there's currently no support for this. You do have the INewRequest event. yeah, i saw that, and that's what i'll use as a workaround. but: a) it's less efficient and smells a little bit bad to me to add an event handler and touch every request instance after it's been created when what i really want to do is add a class variable to the request class b) it doesn't address the response object issue. WebOb provides the ResponseClass attribute on the request object specifically for this purpose, it seems silly not to use it. yes, there's an INewResponse event... see a). put another way, ian bicking specifically recommends that subclasses of Request and Response are a good way to handle certain use cases, and WebOb was designed with that in mind. it seems reasonable to me to support doing so. -r ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] custom Request and Response classes in repoze.bfg
Rob Miller wrote: hey all, so in building my first repoze.bfg app, it's occurred to me that i'd like to use a custom Request and Response classes, just simple subclasses of the WebOb defaults so that i can set configurable class variables like default_charset. unless i'm missing something in the code, there's currently no support for this. how would folks feel about the following changes: - in repoze.bfg.router, the paster config would be checked for request_class setting, which would be a dotted path to a request class to use. absence of this setting means use the default class, nothing changes. I think this is more application configuration than deployment configuration so I think it might be better if an IRequestFactory utility was registered via ZCML to be able to override the request factory used by the Router. I'd be willing to put something like this in there if it didn't cause a noticeable slowdown. - every place that a response object is currently instantiated, use request.ResponseClass instead of explicitly using the WebOb class. AFAICT, response objects are instantiated in the following repoze.bfg modules: - chameleon_[genshi|text|zpt] - view - wsgi - xslt in the 'view' and 'wsgi' modules, we're already holding the request object when the response is instantiated, so there's very little to change. in all of the other modules, the response is being instantiated in a render_[template|transform]_to_response function. Note that you could just write your own render_template_to_response function that used render_template and constructed its own kind of response object with the the result of render_template as the response body. That's effectively all that render_template_to_response does. Such a function could be a single line and you could even give it a shorter name! ;-) the biggest change, then, would be to have all of the render-to-response methods start requiring request objects as arguments. this could be optional at first, w/ a deprecation warning if it's left out, until such time as we might see fit to force the issue. I'd also be willing to make a IResponseFactory utility that chameleon_*, view, wsgi, and xslt used to find what kind of response object to get as long as it didn't slow things down much. It would accept no arguments and always return the same kind of response object. I *think* having a global IRequestFactory utility would give you what you wanted; although it wouldn't be able to use request.ResponseClass, as long as what request.ResponseClass means doesn't differ from request-to-request, you would be able to differ the response class for a particular application. - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] custom Request and Response classes in repoze.bfg
Chris McDonough wrote: Rob Miller wrote: hey all, so in building my first repoze.bfg app, it's occurred to me that i'd like to use a custom Request and Response classes, just simple subclasses of the WebOb defaults so that i can set configurable class variables like default_charset. unless i'm missing something in the code, there's currently no support for this. how would folks feel about the following changes: - in repoze.bfg.router, the paster config would be checked for request_class setting, which would be a dotted path to a request class to use. absence of this setting means use the default class, nothing changes. I think this is more application configuration than deployment configuration so I think it might be better if an IRequestFactory utility was registered via ZCML to be able to override the request factory used by the Router. I'd be willing to put something like this in there if it didn't cause a noticeable slowdown. yes, that occurred to me as well. i'd be fine w/ a utility. - every place that a response object is currently instantiated, use request.ResponseClass instead of explicitly using the WebOb class. AFAICT, response objects are instantiated in the following repoze.bfg modules: - chameleon_[genshi|text|zpt] - view - wsgi - xslt in the 'view' and 'wsgi' modules, we're already holding the request object when the response is instantiated, so there's very little to change. in all of the other modules, the response is being instantiated in a render_[template|transform]_to_response function. Note that you could just write your own render_template_to_response function that used render_template and constructed its own kind of response object with the the result of render_template as the response body. That's effectively all that render_template_to_response does. Such a function could be a single line and you could even give it a shorter name! ;-) yes, that's easy enough, although it seems quite reasonable to me to use the pattern that WebOb intended for this in the bfg core. the biggest change, then, would be to have all of the render-to-response methods start requiring request objects as arguments. this could be optional at first, w/ a deprecation warning if it's left out, until such time as we might see fit to force the issue. I'd also be willing to make a IResponseFactory utility that chameleon_*, view, wsgi, and xslt used to find what kind of response object to get as long as it didn't slow things down much. It would accept no arguments and always return the same kind of response object. I *think* having a global IRequestFactory utility would give you what you wanted; although it wouldn't be able to use request.ResponseClass, as long as what request.ResponseClass means doesn't differ from request-to-request, you would be able to differ the response class for a particular application. i'm not really following you here. i'm -1 on the idea of an IResponseFactory utility. i think having the ResponseClass available on the request objects meets the need here; the hook is already in WebOb, why not just use it? if anything, i'd rather see an ICurrentRequest utility, which always returned the request object for the current request... or some other way to always get at the request object, regardless of whether or not it's been explicitly passed in. if request.ResponseClass is always used when instantiating a response object, then there's no need to support any other pluggability; the request object serves the need just fine w/o requiring another utility. -r ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev