[Zope-dev] traversal: different with and without a request

[Philipp von Weitershausen]

Christian Theune wrote:
> we stumbled over an annoyance that took a while to debug:
> 
> Writing an ITraversable, we used zope.traversing.api.traverse() in a
> test to verify our code. We registered the ITraversable as an
> (non-multi) adapter and ended up with a working test.
> 
> In the actual system, we found that the traversable would not be used.
> After investigation we found a conditional branch in the traverse()
> function which would look for a multi-adapter if a request was around,
> and a regular adapter if not.
> 
> We didn't anticipate this difference and it cost us some time, so we
> wonder whether this has to be the way it is, or whether this could be
> changed to behave more obvious and consistent.

zope.traversing is a mess.

First of all, its name is quite misleading. It should really be called 
'zope.resolvepath' because it resolves TALES-like object paths. In fact, 
it's pretty much only used by the PageTemplate machinery to hook it up 
to the TALES engine (with one exception, see below). The request 
shouldn't really be necessary for this kind of path resolution, I think. 
  The conditional multi-adaption sounds like a DWIM feature that I would 
consider one of our many mistakes that we made in the beginnings of our 
using the Component Architecture.

There is a process that actually needs the request and this process is 
what I call traversal: breaking down a URL and finding a publishable 
object. zope.traversing has (almost) nothing to do with it, the real 
kind of traversal happens in the publisher and facilitates 
IPublishTraverse adapters (rather than ITraversable). The only case when 
the two kinds of "traversal" are intermingled is when ++namespaces++ are 
involved. Then IPublishTraverse-style traversal uses ITraversable 
adapters. This has long been considered a mistake but was never fixed.

I'm not sure my explanation are helpful ;). Did I mention it was a mess?