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  
> request.publication.
> 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  
getDefaultTraversal method.

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.


Jim Fulton
Zope Corporation

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to