[Zope-dev] Re: Subpath traversal interface (was RE: ANN: Python Methods 0.1.7 up and over to DC) and over to DC)

Evan Simpson evan@4-am.com
Tue, 14 Dec 1999 18:20:41 -0600


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