Kevin Dangoor wrote:
On 1/11/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
I had not seen that, thanks for noting that. Added myself to CC as
well. As I look through the CherryPy code, maybe it would be possible
to figure this out with a sufficiently magical cherrypy.root object,
though I suspect some serious monkeypatching to cherrypy.config might
also be necessary (to make up for no complete and global set of
configuration), and I might just need to make cherrypy.root a
threadlocal object. That's probably the thing most likely to work.
I'm curious to know what the use cases are that actually don't work
with the new CP implementation.
With Paste Deploy, an application only knows where it lives when a
request is run, which is the primary issue. I imagine the basic setup
looking like:
[main:app]
root_object = mypackage.root
Though I'm not sure exactly how TG does it, I'm just thinking from
CherryPy now. When a request is sent to this application, SCRIPT_NAME
indicates where the application was found -- it isn't known ahead of
time. This means various programmatic dispatching tricks are possible.
And it also just happens to be the only way Paste Deploy communicates
this base URL to the application.
The tree stuff in CherryPy assumes that there is a single fixed url
where each object is mounted, and then I think builds up the
cherrypy.root object based on that.
The way I am experimenting with now is for cherrypy.root itself to be a
threadlocal object, and then a request comes in we make that object act
like whatever the configured root is (i.e., dispatching all attribute to
mypackage.root). Then we don't have to build up a fake tree at all,
instead it always looks to CherryPy as though there is only one
application being served. (Configuration also has to be fixed up like
this, which seems less obvious to do, but probably reasonable too).
It's a little wonky feeling -- if the root object was just an argument
instead of a global (which is really all I'm looking for) then this
would feel much more elegant. And frankly the code would look better
too. But a threadlocal isn't so bad, all considered -- it feels a lot
cleaner to me than constructing a tree, and is fairly easy to put into
place.
I haven't tested this at all (not even syntax ;) and I really should be
doing other things at the moment so I won't test it for a while, but a
basic prototype is at http://svn.colorstudy.com/home/ianb/CherryPaste/trunk
cherrypy.request and cherrypy.response are threadlocal proxy objects
already, if you feel that such an approach is required. That was what
I had originally expected would be done in CP, but fumanchu decided to
change the API a little bit with the tree mounting stuff (which is
fine).
A positive part of a monkeypatch is that it will be immediately usable
with TG, probably/hopefully without TG needing to know that. Though I
suspect there may be some configuration issues... is TG still using
CherryPy's configuration, or is it starting to handle that on its own?
TurboGears still uses CherryPy's configuration, but the files have
changed to Python modules that return a nested dictionary. This can be
transformed if need be.
Paste Deploy uses pretty dumb ini files, which isn't that far from
CherryPy's normal configuration, which is good. OTOH, I see the issue
you are trying to deal with -- lots of "configuration" is really about
describing how the application is built, and isn't something you
configure on a per-installation basis. The ambiguity comes in when
"application" becomes confused -- I think the original CherryPy
perspective was that CherryPy is the application, and you configure it
with respect to your Python code. As the perspective shifts towards a
framework, the application's configuration and the framework's
configuration can become confused.
As I've been encountering this, I've been writing translation functions
basically. They take the (minimal) application configuration, and apply
defaults (which are often calculated) and often add in framework
configuration (like that 'root_object'). So with Paste Deploy you would
probably not point to CherryPaste in your entry point, but to some
module (I've been calling it wsgiapp) and doing:
def make_app(global_conf, **app_conf):
return cherrypaste.pastify.make_app(
global_conf, root_object='myapp.root', **app_conf)
Another way to handle this would be to import a module, and add all the
global variables from that module, which approaches what I think you are
doing.
But anyway, if you can handle a degree of ini-based configuration (with
the slightly different semantics that implies, such as things like lists
and dicts are hard to construct compared to Python code) then I think
that should make it easier to apply Paste later.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
