RE: [Zope-dev] Re: Subpath traversal interface (was RE: ANN: Pyth on Methods 0.1.7 up and over to DC) and over to DC)
-----Original Message----- From: Evan Simpson [mailto:evan@4-am.com] Sent: Tuesday, December 14, 1999 2:59 PM To: Michel Pelletier Cc: 'Phillip J. Eby'; zope-dev@zope.org Subject: Re: [Zope-dev] Re: Subpath traversal interface (was RE: ANN: Python Methods 0.1.7 up and over to DC) and over to DC)
It's a wafer-thin cost, really! :-)
it was Jim's objection, but I see the logic.
I'll be interested to see your implementation. Both SiteRoots and Access Rules depend abjectly on the hook. SiteRoots hook into their containers' traversal so that they can call REQUEST.setURL.
We just do this from __bobo_traverse__ if self.base == REQUEST['SERVER_URL'].
Designating an object as an Access Rule causes it to be called before its container is entered, which allows the path foolery necessary for (my version of) virtual hosting.
Most of the path foolery I think you're talking about is not needed now because absolute_url is now recursive. The Rule thing though, that might need to hook, I'd have to bug Jim about it.
When I was first designing SiteAccess, I considered hooking __bobo_traverse__, but I was really worried about what to do if a container already implemented it,
Then that container can't be a SiteObject.
or if a SiteRoot and an Access Rule wanted to share the same container.
SiteRoots are containers, and we haven't implimented Access Rules yet...
It would be great if __bobo worked like __before, but I imagine that it's a bit late to be changing that one.
How would you like the behavior to change?
I have been struggling with the new absolute_url implementation, by the way. It makes perfect sense, and would work fine with a virtual hosting solution which can insert an object into the acquisition chain. Sadly, mine can't.
Maybe Jim can explain this better, but we find a very pleasent isomorphism between SiteObjects, Portal Objects, and virtual hosting, this is why we have a new object type that gets 'inserted' into the chain. Since a Siteobject works just like a folder, except for the URL rewriting (and that doesn't happen if the SERVER_URL doesn't match the base URL of the virtual host) then you are really only inserting a folder, but a sorta special folder that knows some tricks. -Michel
Michel Pelletier wrote:
I'll be interested to see your implementation. Both SiteRoots and Access Rules depend abjectly on the hook. SiteRoots hook into their containers' traversal so that they can call REQUEST.setURL.
We just do this from __bobo_traverse__ if self.base == REQUEST['SERVER_URL'].
Ah. You make a special kind of folder to be a site container, where I do a drop-in on an existing container. Different design philosophies. There aren't yet (AFAIK) any non-Folder Folderish objects in common use, but if one arises it will be possible to make it a SiteRoot. On the other hand, absolute_url is a pain for me.
Most of the path foolery I think you're talking about is not needed now because absolute_url is now recursive. The Rule thing though, that might need to hook, I'd have to bug Jim about it.
No, the path foolery I'm talking about is the addition/alteration of path elements in the traversal path while traversal is taking place. For example, if 'http://www.site.com/' should resolve to '/site/', an Access Rule in the root can add the 'site' element to the (initially empty) path. Also, I have a shopping cart system where '.../catalog/cart=2345/...' is converted to '.../catalog/...' and 'cart=2345' saved in the REQUEST by an Access Rule in 'catalog'.
It would be great if __bobo worked like __before, but I imagine that it's a bit late to be changing that one.
How would you like the behavior to change?
Well, __before_traverse__ isn't a method. It's a dictionary whose keys are application-defined, and whose values are the names of attributes of the container. These attributes are presumed to be callables, and will be called with the container and request, in the same order as their keys' sort order. This means that an application can safely add and remove hooks without affecting other applications' hooks, and can control invocation order. Either contained objects or methods of the container can be pointed at, without causing any reference loops. If the target is deleted or renamed, it will be silently removed from the dictionary on the next traversal attempt.
Maybe Jim can explain this better, but we find a very pleasent isomorphism between SiteObjects, Portal Objects, and virtual hosting, this is why we have a new object type that gets 'inserted' into the chain. Since a Siteobject works just like a folder, except for the URL rewriting (and that doesn't happen if the SERVER_URL doesn't match the base URL of the virtual host) then you are really only inserting a folder, but a sorta special folder that knows some tricks.
As I said, different design concept. If I felt safe hooking __bobo_traverse__, I'd probably do it that way too. Hmm. The way things have worked out, SiteRoots care about __bobo, but Access Rules don't. I suppose I could have SiteRoot overwrite (and save and chain to) its container's __bobo, and put it back if it loses track of the SiteRoot. I may try that. Can you usefully nest SiteObjects? I have a site where shop.foo.com's target lives in a folder inside of www.foo.com's target. Thanks, Evan @ 4-am
Argh. Evan, you're an idjit. Rub those two thoughts together. Evan Simpson wrote:
No, the path foolery I'm talking about is the addition/alteration of path elements in the traversal path while traversal is taking place.
I suppose I could have SiteRoot overwrite (and save and chain to) its container's __bobo, and put it back if it loses track of the SiteRoot. I may try that.
I can just have SiteRoots add *themselves* to the traversal path, and they can merrily add the necessary absolute_url fixer to the chain. Expect SiteAccess 0.2.0 later tonight, folks. Cheers, Evan @ 4-am
participants (2)
-
Evan Simpson -
Michel Pelletier