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
> 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
> how would folks feel about the following changes:
> - in repoze.bfg.router, the paster config would be checked for
> 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
> - 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.
Repoze-dev mailing list