While musing on the Zen of Zope, and the uses to which it has been put, it occurred to me that it might be very useful to have an equivalent to bobo_before on ordinary Zope objects. By this, I mean the ability to specify a method of an object which is to be evaluated when that object is traversed. The method should be evaluated in the same kind of context as if it were the ultimate target of the request, so that it has access to all REQUEST information, acquisition, etc. I realize that this can sort of be done now for custom objects using __bobo_traverse__, but the uses I envision would involve ordinary stock Zope objects, especially Folders. The effect I'm looking for would be similar to starting a document with a loop through PARENTS, finding and rendering a special method of each parent. It would differ in that the document need not invoke the loop in an explicit fashion, and indeed could not prevent its invocation. Is this already doable? Is there some reason why it cannot or should not be done? A rather bad example of what I'm aiming for would be a method which munges REQUEST data for every request passing through a particular folder, or even intercepts and redirects the request. It would be possible to have a Filters folder in the root, and write URLs like: http://myhost.com/Filters/preloaddata/munge3/area/subject What originally got me onto this track was the idea of treating certain properties like cascading stylesheets, where properties along an access path are additive. This is in contrast to acquisition, where properties further along the access path replace earlier-accessed properties of the same name. With filter methods, data can be accumulated in a list or dict in REQUEST. Enough of my rambling. Comments?