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

[Sidnei da Silva]

On Mon, Oct 04, 2004 at 09:23:52AM -0400, Tres Seaver wrote:
| >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

Gee, I must have been drunk by the time I grepped :P

| >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.

Yes, looking at it again, that seems correct. Still I don't see an
easy way to avoid the exception in PageTemplate's
restrictedTraverse. Or do you mean it should indeed raise the
exception there?

| >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).

Yes, but even the Publisher is confused there, afaics. It does
correctly handle AttributeError/KeyError into a NotFound for
everything, except for __bobo_traverse__:

BaseRequest:301 (Zope-2_7-branch)
==========================================================================
        try:
          <snip>
                if hasattr(object,'__bobo_traverse__'):
                    subobject=object.__bobo_traverse__(request,entry_name)
                    if type(subobject) is type(()) and len(subobject) > 1:
                        # Add additional parents into the path                     
                        parents[-1:] = list(subobject[:-1])
                        object, subobject = subobject[-2:]
                else:
                  <snip handling of AtributeError into NotFound>
           <snip>
         finally:
            ...
==========================================================================

If I understand the above correctly, it will end up not handling the
AttributeError for __bobo_traverse__, thus resulting into a 500
response instead of 404.

-- 
Sidnei da Silva <sidnei at awkly.org>
http://awkly.org - dreamcatching :: making your dreams come true
http://www.enfoldsystems.com
http://plone.org/about/team#dreamcatcher

A programming language is low level when its programs require attention
to the irrelevant.