Max M wrote at 2006-11-29 12:53 +0100:
>Dieter Maurer skrev:
>> Yuri wrote at 2006-11-28 14:23 +0100:
>>> here: http://docs.neuroinf.de/programming-plone/ate we can read:
>>>
>>>obj = brain.getObject().aq_base
>>>
>>> why .aq_base and not only brain.getObject()? :)
>>
>> Usually, it is a bad idea to use "aq_base" in Zope applications
>>
>> You should carefully examine the context of the code fragment above.
>> Maybe, the context is one of the rare situations where "aq_base"
>> is called for...
>
>Why is it rare?
>
>I often need to check if an object has a certain attribute. Getting
>aquisition into the mix is a bad idea there.::
>
> name = getattr(obj, 'name')
>
>Is a lot different than
>
> name = getattr(obj.aq_base, 'name')
>
>In the first example you don't know if the name attribute is an aquired
>object or an attribute on the actual object. Which can make for
>uncontrollable results.
You may use it often -- but you may then work suboptimally :-)
You are right that "getattr(obj, 'name')" and "getattr(obj.aq_base, 'name')"
are quite different -- in that the first acquires "name" if "obj" does
not have such an attribute. On the other hand "getattr(obj.aq_base, 'name')"
is adequate only for simple result object types -- those that do not
support acquisition. If the result supports acquisition,
then the result is only partially acquisition wrapped.
Partially acquisition wrapped objects tend to produce interesting
surprises: they get e.g. 'getPhysicalPath' and 'absolute_url'
wrong and cannot access 'REQUEST'.
For your use case above, I have therefore proposed
an "hasattr_unacquired" standard function ages ago (the Zope
tracker will show you when exactly). Here, the name explicitly
spells out what the function is used for -- such that
even a newbie can understand what is happening (which might
not be the case with an "obj.aq_base" use).
Such an "hasattr_unacquired" drastically reduces the need
to use "aq_base" (or the even more horrible "aq_inner.aq_explicit"
variant for untrusted code).
--
Dieter
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
