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