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: Monday, December 20, 1999 7:34 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)
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?
I guess they're shaping up to be top level methods of a portal object. What methods get to be 'portal methods' is still not a concrete concept.
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.
I think what we are going to end up doing is releasing a small, general purpose object to do the virtualhosting. It will be a mixin class that hooks __b_t__ and absolute_url(). As a 'Product' we will be developing a simple object based on Folder and this new class, SiteObject. Further, the SiteObject class will be used for our 'PortalObjects'. So, you can use the stock object which is simple, folderish; or you can use the portal object which will be more complex, or you can roll your own by inheriting SiteObject and whatever, ZClass or Python, etc. Now the path manipulation thing sounds like it should be some seperate genetic material that is subclassable and realizable by a simple 'Rule' object. I think that this object's elaboration, while related to the genetic material that forms virtualhosting, should be developed without mixing them together too much. Sorta the same thing we did with Virtual hosting, we folded your functionality into the core; it might be useful to fold path manipulation logic into the core and realize it the same way, subclassable, simple object (not, I would imagine, unlike your Rule object) a snip of genetic material that can be mixed in at any time. I suspect I'm beginning to see your side of the argument, A 'Rule' mixin would conflict with the SiteObject mixin if they both wanted to hook __b_t__, so your __before__ hook was a way to chain calls like this? -Michel
Michel Pelletier wrote:
I suspect I'm beginning to see your side of the argument, A 'Rule' mixin would conflict with the SiteObject mixin if they both wanted to hook __b_t__, so your __before__ hook was a way to chain calls like this?
Pretty much, although "chaining" isn't quite the right word for it. It simply keeps a sorted collection of methods and invokes them all. I did originally consider chaining __bobo_traverse__ -- saving the existing method (if any), calling it after my object's hook was done, restoring it when my object was deleted, etc. The fact that _b_t_ can (in fact, is meant to) replace the current traversal object makes the semantics of such chaining troublesome. If one _b_t_ method replaces the current object, would it make any sense to call further _b_t_ methods of the old object? Cheers, Evan @ 4-am
On 20 Dec 1999 23:25:01 -0600, Evan Simpson wrote:
Michel Pelletier wrote:
I suspect I'm beginning to see your side of the argument, A 'Rule' mixin would conflict with the SiteObject mixin if they both wanted to hook __b_t__, so your __before__ hook was a way to chain calls like this?
Pretty much, although "chaining" isn't quite the right word for it. It simply keeps a sorted collection of methods and invokes them all. I did originally consider chaining __bobo_traverse__ -- saving the existing method (if any), calling it after my object's hook was done, restoring it when my object was deleted, etc. The fact that _b_t_ can (in fact, is meant to) replace the current traversal object makes the semantics of such chaining troublesome. If one _b_t_ method replaces the current object, would it make any sense to call further _b_t_ methods of the old object?
This is starting to sound a lot like the Predicate behavior that Phillip Eby mentioned a while back. Hopefully we'll hear more on that subject in the near future as it may provide solutions for a number of similar existing Zope limitations. This could effectively deal with site access situations as well as the more complex permissions behaviors that currently require fairly ingenious and convoluted mechanisms. Might also provide solutions for the Datamining and Local Filesystem filtering problems. As to the Event model that Michel mentioned, almost all of my zope projects are applications that really do need the capability to cache and handle different types of short-term, volatile objects. This is most evident in the Local FS and Datamining concepts.
participants (3)
-
Evan Simpson -
kent＠tiamat.goathill.org -
Michel Pelletier