Hi, I just read an old thread about overriding __getattr__ without breaking acquisition. Using Implicit.inheritedAttributes('__getattr__') didn't work, and I'm not sure if using Implicit.__class__.__getattr__ even gives me the correct __getattr__? Anyway I found a way around this using __dict__ explicitly. In the __of__ wrapper I save the parent: self.__dict__['_v_parent']=parent and in the end of __getattr__ I put if self.__dict__.has_key('_v_parent'): return getattr(self.__dict__['_v_parent'], name) It seams to work, but I just want to check for any problems with this approach. Best Regards, Johan Carlsson -- Easy Publisher Developers Team Johan Carlsson johanc@easypublisher.com Mail: Birkagatan 9 SE-113 36 Stockholm Sweden Phone +46-(0)8-31 24 94 Fax +46-(0)8-673 04 44 Mobil +46-(0)70-558 25 24 http://www.easypublisher.com
Johan Carlsson [EasyPublisher] wrote at 2003-4-16 14:12 +0000:
I just read an old thread about overriding __getattr__ without breaking acquisition. Using Implicit.inheritedAttributes('__getattr__') didn't work, and I'm not sure if using Implicit.__class__.__getattr__ even gives me the correct __getattr__?
Jim (Fulton) has removed the need to call the inherited "__getattr__" from "Persistent".
Anyway I found a way around this using __dict__ explicitly.
This is to avoid acquisition which is likely to cause ininite recursion (silently broken by the "RuntimeError: too many recursion" (or so).
In the __of__ wrapper I save the parent: self.__dict__['_v_parent']=parent
and in the end of __getattr__ I put
if self.__dict__.has_key('_v_parent'): return getattr(self.__dict__['_v_parent'], name)
It seams to work, but I just want to check for any problems with this approach.
Are you sure, you need "__getattr__"? Acquisition would automatically look for "name" in "parent" when "self" does not have this attribute. Dieter
Johan Carlsson [EasyPublisher] wrote:
Hi, I just read an old thread about overriding __getattr__ without breaking acquisition. Using Implicit.inheritedAttributes('__getattr__') didn't work, and I'm not sure if using Implicit.__class__.__getattr__ even gives me the correct __getattr__?
Anyway I found a way around this using __dict__ explicitly. In the __of__ wrapper I save the parent: self.__dict__['_v_parent']=parent
and in the end of __getattr__ I put
if self.__dict__.has_key('_v_parent'): return getattr(self.__dict__['_v_parent'], name)
It seams to work, but I just want to check for any problems with this approach.
Hmm, you might not need to do all of that. The acquisition wrapper first consults your __getattr__(). If your __getattr__() raises an AttributeError, the acquisition wrapper continues its search for the attribute along the normal acquisition chain. All you have to do is raise AttributeError, which you should do anyway. Shane
At 16:17 2003-04-16 -0400, Shane Hathaway said:
Johan Carlsson [EasyPublisher] wrote:
Hi, I just read an old thread about overriding __getattr__ without breaking acquisition. Using Implicit.inheritedAttributes('__getattr__') didn't work, and I'm not sure if using Implicit.__class__.__getattr__ even gives me the correct __getattr__? Anyway I found a way around this using __dict__ explicitly. In the __of__ wrapper I save the parent: self.__dict__['_v_parent']=parent and in the end of __getattr__ I put if self.__dict__.has_key('_v_parent'): return getattr(self.__dict__['_v_parent'], name) It seams to work, but I just want to check for any problems with this approach.
Hmm, you might not need to do all of that. The acquisition wrapper first consults your __getattr__(). If your __getattr__() raises an AttributeError, the acquisition wrapper continues its search for the attribute along the normal acquisition chain. All you have to do is raise AttributeError, which you should do anyway.
It works! Aha... Great, thanks. The problem was that here in ZPT didn't act as I thought it would. I though it would act as context in Python Scripts. Validating my tests with a Python Script, a Python Method and a DTML Method. and also using template/variable_name instead of here/variable_name proved it to work. What's up with here in ZPT? Best Regards, Johan Carlsson -- Easy Publisher Developers Team Johan Carlsson johanc@easypublisher.com Mail: Birkagatan 9 SE-113 36 Stockholm Sweden Phone +46-(0)8-31 24 94 Fax +46-(0)8-673 04 44 Mobil +46-(0)70-558 25 24 http://www.easypublisher.com
Johan Carlsson [EasyPublisher] wrote:
It works! Aha... Great, thanks. The problem was that here in ZPT didn't act as I thought it would. I though it would act as context in Python Scripts. Validating my tests with a Python Script, a Python Method and a DTML Method. and also using template/variable_name instead of here/variable_name proved it to work.
What's up with here in ZPT?
Hmm, "here" in page templates should be equivalent to "context" in Python scripts, and I can't think of anything that would make it otherwise. Sorry. Shane
participants (3)
-
Dieter Maurer -
Johan Carlsson [EasyPublisher] -
Shane Hathaway