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

[Michel Pelletier]

> -----Original Message-----
> From: Evan Simpson [mailto:evan@4-am.com]
> Sent: Tuesday, December 14, 1999 7:21 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)
> 

This was one of those windows that i minimized and found five days
later. ;)

> 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.

I, personally, prefer the folderish approach.  If a site root is a
definitive folder, then 'portal' like methods can be placed in it,
giving the virtual host a more OO feel, but that's just a design issue.
Jim has gotten into the habit of drawing little ships portals (to
concentric circles with bolts around it) when talking about a portal.
He and I both assumed the folder arch when we thunk up Zope's
virtualhost support.  The beauty of our solution, I think, is the size
of the change, absolute URL was actually simplified, one short method
was added to REQUEST, and a very simple folder object was created that
overrides absolute_url and __bobo_traverse__.  All in all, suprisingly
little code.

But really the whole guts of the operation is done in the
REQUEST.setBase() and absolute_url() methods.  If you object impliments
that interface, it doesn't really matter if it's folderish or not.  I
think the issue is mostly the hook.
 
> 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'.

That's pretty nifty.  I believe we want that, what we need to figure out
is the best way to do manipulations like that.  You're using a Rule
object now, probably makes sense at the application level to not change
that and have identical Rule objects in interface, but investigate how
it's to be done.  If there is a discrete folder object like we have now,
is the before hook needed at Rule time?

> > 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.

What I think your hitting on here Evan is the beginnings of an Event
model.  Zope cannot ignore these issues for long, especially with
workflow concepts becoming decernable in the mist.

> 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.

Untested, but I guess yes.  If the base URL doesn't match the
SERVER_URL, no rewriting is done and the object looks just like a
folder.

-Michel

> 
> Thanks,
> 
> Evan @ 4-am
>