On Oct 15, 2008, at 12:02 PM, Philipp von Weitershausen wrote:
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.
That's a bit strong, but essentially true. It zope.traversing deserves to be reworked if anyone has the time and energy.
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).
Historical note. Until we decided to use the location framework and eschew traversal proxies, is was much more widely used. It would be nice to deprecate zope.traversing and fold it into zope.app.pagetemplate.
The request shouldn't really be necessary for this kind of path resolution, I think.
It's needed for looking up views and resources, both of which are commonly looked up in ZPT.
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.
<shrug /> I'll note that the fix, in the context of ZPT is to always to a multi- adapter lookup using the request.
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).
Yup.
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.
Yup. I would go so far as to call it a bug. Somebody please fix it. :) Jim -- Jim Fulton Zope Corporation