Hi! here: http://docs.neuroinf.de/programming-plone/ate we can read: obj = brain.getObject().aq_base why .aq_base and not only brain.getObject()? :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28 Nov 2006, at 14:23, Yuri wrote:
Hi!
here: http://docs.neuroinf.de/programming-plone/ate we can read:
obj = brain.getObject().aq_base
why .aq_base and not only brain.getObject()? :)
You are not presenting this one line in its context. No one will be able to tell you whether that is necessary wherever it is mentioned, because no one knows the stuff you omitted. In normal situations "getObject" is all you need. I don't know any standard situation where you would not want the returned object acquisition-wrapped. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFbHEyRAx5nvEhZLIRAnC3AJ9bwRC7ca3l+1KKA1F1M6cN9972RACglzQI QaSWjPJb6566aB1AHY+kZAI= =HOTR -----END PGP SIGNATURE-----
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 (there are special cases where it is the right thing though). The reason: Zope usually expects to work with acquisition wrapped objects. "aq_base" discards the acquisition context. 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... -- Dieter
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. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science
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
Dieter Maurer wrote:
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).
Hey, you've got commit access now, there's nothing stopping you adding this ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (5)
-
Chris Withers -
Dieter Maurer -
Jens Vagelpohl -
Max M -
Yuri