On Jun 20, 2009, at 1:10 PM, Jim Fulton wrote:
> Why? traverseName is part of zope.app.publication's
> implementation. Now it's oddly split off in a very separate
> package. This makes customizing publication behavior more difficult.
> I recently made proxying overridable and missed traverseName.
> This should be moved back to zope.app.publication. The only other
> thing that uses this is zope.app.publsher.browser.menu. That can and
> should get to these methods via request.publication.
> Or, better yet, traverseRelativeURL and traversePath should be moved
> to the browser module and should get traverseName from
> I'll go ahead and do this.
Unless something other than zope.app.publication.ZopePublication is
using PublicationTraverser (or PublicationTraverse) as a base class.
I'm guessing that this isn't likely.
The tests for PublicationTraverser either need it to provide
traverseName or they need the request to have a publication that has
traverseName. But the tests don't want to depend on
Also, traverseRelativeURL really wants to use the publication
I'm going to wager that the intent of
zope.traverser.publicationtraverse is *not* to provide a publication
base class. I'm going to refactor the tests so that they have a test
publication with minimal traverseName and getDefaultTraversal.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -