Inconsistent aq-wrapping in BaseRequest's traverseName()

[Martin Aspeli]

I *think* this is a bug, opinions welcome :)

In ZPublisher/BaseRequest.py, we have this:

    def traverseName(self, ob, name):
        if name and name[:1] in '@+':
            # Process URI segment parameters.
            ns, nm = nsParse(name)
            if ns:
                try:
                    ob2 = namespaceLookup(ns, nm, ob, self)
                except TraversalError:
                    raise KeyError(ob, name)

                return ob2.__of__(ob)

        if name == '.':
            return ob

        if IPublishTraverse.providedBy(ob):
            ob2 = ob.publishTraverse(self, name)
        else:
            adapter = queryMultiAdapter((ob, self), IPublishTraverse)
            if adapter is None:
                ## Zope2 doesn't set up its own adapters in a lot of cases
                ## so we will just use a default adapter.
                adapter = DefaultPublishTraverse(ob, self)

            ob2 = adapter.publishTraverse(self, name)

        return ob2

Notice that when it does a namespaceLookup, it will aq-wrap the result. Thus, if you write an ITraversable adapter for a ++foo++ namespace, you should not aq-wrap the result. This is generally good IMHO, because it makes it possible to re-use pure-Zope3 adapters.

Now, if we do a publishTraverse() the result is not aq-wrapped, leading to the usual problems (like the bizarre authentication errors that stung me). It also means that you have to write your own IPublishTraverse adapter for things like containers. For example, if you try to traverse to the content of a Zope 3 style container, zope.app.container.traversal.ItemTraverser is insufficient. Of course Five could provide an override that aq-wrapped the result, but it still seems strange that the two exit points are inconsistent.

Note that IPublishTraverse may also look up views and return them, which also need to be aq-wrapped.

[Hanno Schlichting (hannosch)]

This still applies to current Zope 2.12 code. But given that this has worked for years, I'm not sure if we should change it.

[Martin Aspeli (optilude)]

How about a conditional: If the result is wrappable (provides IAcquirer), but has no aq chain, wrap it, otherwise leave it alone?

[Colin Watson (cjwatson)]

The zope2 project on Launchpad has been archived at the request of the Zope developers (see https://answers.launchpad.net/launchpad/+question/683589 and https://answers.launchpad.net/launchpad/+question/685285). If this bug is still relevant, please refile it at https://github.com/zopefoundation/zope2.