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.


Repoze-dev mailing list

Reply via email to