[Repoze-dev] custom Request and Response classes in repoze.bfg

2009-01-14 Thread Rob Miller
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-01-14 Thread Malthe Borch
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

2009-01-14 Thread Rob Miller
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

2009-01-14 Thread Chris McDonough
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

2009-01-14 Thread Rob Miller
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