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 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
Michel Pelletier wrote:
I, personally, prefer the folderish approach. If a site root is a definitive folder, then 'portal' like methods can be placed in it,
I'm not sure I understand what 'portal' methods are. Are we talking about methods which, for example, should only be used in a SiteObject, and not in an ordinary folder? Or are they something else?
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.
I ended up re-complicating absolute_url for my purposes; I added a check for self._v_absolute_url, which is returned instead of 'recursive call + id' when it exists. That way, REQUEST.setURL can get the modified URL into the acquisition chain without fooling with it, affecting other threads, or causing a persistent change. Your way is, of course, much easier. Apart from that, and the addition of the __before hook, SiteAccess is also quite small (~200 lines). [path foolery]
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?
Well, yes, unless you add Rule-aware machinery to the standard Folder class (or ObjectManager?). I'd hate to have to replace a Folder with a RuleFolder (or whatever) just because I wanted a Rule in it. Note that there isn't technically such a thing as a Rule object (in the sense of a distinct class). Any DTML Method or Document, External Method, or Python Method can be a Rule. Also, a Rule can manipulate the traversal path more simply than a __bobo_traverse__ could, since it only concerns itself with Ids, not actual objects. Cheers, Evan @ 4-am
participants (2)
-
Evan Simpson -
Michel Pelletier