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 )

Reply via email to