[z3-five] Re: Traversal issue [was: 0.2 release]

[Tres Seaver]

Sidnei da Silva wrote:
> | I'm rather horrified such a thing should be necessary, and also 
> | concerned about performance implications.
> | 
> | I'm confused why we need to do all this special work while Zope itself 
> | does not. Zope doesn't have any code unwrapping the call stack just to 
> | determine how the code was called, right? What's different here?
> 
> No 'sane' code seems to implement __bobo_traverse__.

We have a fair amount of code which does implement it, although 
__getitem__ is often easier to get right.  Here is code in the core 
which *does* implement it:

   $ find . -name "*.py" | xargs grep -l "def __bobo_traverse__"
   ./lib/python/AccessControl/securitySuite/SecurityBase.py
   ./lib/python/App/ApplicationManager.py
   ./lib/python/App/FactoryDispatcher.py
   ./lib/python/App/Product.py
   ./lib/python/HelpSys/HelpUtil.py
   ./lib/python/OFS/Application.py
   ./lib/python/OFS/PropertySheets.py
   ./lib/python/OFS/tests/testTraverse.py
   ./lib/python/Products/OFSP/Draft.py
   ./lib/python/Products/PageTemplates/PathIterator.py
   ./lib/python/Products/SiteAccess/VirtualHostMonster.py
   ./lib/python/Products/ZCatalog/ZCatalogIndexes.py
   ./lib/python/Shared/DC/ZRDB/DA.py
   ./lib/python/ZClasses/Method.py
   ./lib/python/ZODB/ZApplication.py
   ./lib/python/webdav/NullResource.py


> In fact, I
> couldn't find a example of how it should look like. It's really
> annoying that the consumers of __bobo_traverse__ expect it to always
> return something and never raise an exception. 

Lots of implementors raise various exceptions. 
OFS.Traversable.Traversable.unrestrictedTraverse catches exceptions when 
provided with a default.  The 'restrictedTraverse' in PageTemplates 
doesn't take a default, and therefore propagates exceptions.

> An idea just occurred me: We could try to return an dummy object which
> doesn't have __bobo_traverse__ and then:
> 
> - Raise NotFound when the object is published by ZPublisher
> - Raise AttributeError/KeyError when restrictedTraverse tries to
>   traverse further on that object.

I don't understand the rationale for avoiding AttributeError / KeyError 
during a publishing traversal;  *many* places already can / do raise 
such errors.  Trying to DWIM that into a NotFound error in Five only 
covers over application errors (only the Publisher is in the right 
position to do the DWIM, anyway).

> That seems to be a bit cleaner, and doesn't break any assumptions made
> by __bobo_traverse__.


Tres.
-- 
===============================================================
Tres Seaver                                tseaver at zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com