Michel Pelletier wrote:
It seems to me that what is wanted is a "traversable object", rather than a traversable method. That is, at least for the places where I've wanted to use such a thing, I wanted to be able to define a "__bobo_traverse__" with a PythonMethod. But then, I don't want the whole path from there either, I just want to be able to get the next element. In any case, it seems to me that the best way to do this is create a Traversable base class that can be used in ZClasses, that defers __bobo_traverse__ to a method name ZopeTraverse or some such. Then that method can be implemented in the ZClass however it is desired, whether by a PythonMethod, DTML method, or even an SQL method, if appropriate.
IMHO, this doesn't belong in PythonMethods at all.
I think I agree there. Subclassing traversability sounds cleaner.
I agree. Chalk it up to laziness, again; It was *soo* easy to add Yet Another Feature. Foo, you guys are going to make this all clean and orthogonal, aren't you. :-) On another note, the capability described above is actually quite similar to the __before_traverse__ behavior which SiteAccess hacks into the traversal machinery. An Access Rule can look ahead one or more path elements, and then easily manipulate, add, or remove them. Also, multiple objects can hook into the same folder's __b_t__ chain without colliding and with controllable invocation order, which is part of why I invented it rather than overriding __bobo_traverse__. Any chance that DC could incorporate it (the __before_traverse__, I mean)? It's quite clean and well tested at this point, and I could stop nervously examining each release of Zope to see if it will break SiteAccess. Cheers, Evan @ 4-am