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.