[Zope-dev] Re: Subpath traversal interface (was RE: ANN: Python Methods 0.1.7 up and over to DC) and over to DC)

[Evan Simpson]

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