On Fri, Dec 23, 2005 at 11:42:23AM -0500, Kevin Dangoor wrote: > > On 12/22/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > After following the form and widget threads for a while, I finally did > > a little experimental hacking today, and found a few little itches -- > > that is, small annoyances that can be solved with a little localized > > application of force. :) > > A little localized application of force is fine, and I'm sure there > are *many* nits with the current implementation. My concern is to make > sure there's no glaring "structural" errors. I wouldn't want to create > the Tacoma Narrows Widgets: > http://www.enm.bris.ac.uk/research/nonlinear/tacoma/tacoma.html > > > Here are the things that bugged me today -- > > > > * Controllers want a handle into cherrypy.request. The base controller > > class ought to grab one, so that any controller method can see the > > request in self.request. This helps with unit testing (no need to mock > > a cherrypy module just to mock the request) -- and generally, it makes > > sense to me to put things near where they are going to be used. > > I don't really mock the cherrypy package for testing. I just toss in a > fake request. Adding a self.request reference to the controller seems > reasonable for convenience's sake. Can you open a ticket for that? > (http://trac.turbogears.org)
I hadn't thought about this till now, what's the implication in multi-threaded environments? If two requests can be executing at the same time, cherrypy.request will always point to request for that thread, but will self.request? Also, currently, my sub-controllers don't extend the RootController. In theory, they don't have to, unless this change goes through. Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.
pgpDNC7FR1SaI.pgp
Description: PGP signature
