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?
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -