Re: [Zope-dev] ComputedAttribute, Persitent and too many datafull base classes
At 03:44 PM 10/20/01 +0200, Godefroid Chapelle wrote: Hi, In a product I am writing, I am trying to add a ComputedAttribute to an instance of a Folder descendant class. This is the code I use: def addComputedAttribute(self, attributeName, sourceCode): methodName = '_ca_get%s' % attributeName self.addMethod(methodName, sourceCode) setattr(self, attributeName, ContextComputedAttribute(self.__class__.__dict__[methodName])) I think the problem you're having is that the method object being used in the last line (i.e., self.__class__.__dict__[methodName]) is not persistent. If it is a Python function, it will not be saved persistently within the computed attribute. This is probably why the Zope instance crashes at a later time. This doesn't have anything to do with whether ComputedAttribute is Persistent. It doesn't need to be, which is a good thing because you can't derive a class from both (as you've discovered). You can write a Python version of ComputedAttribute by deriving only from Persistent, but as I said there is really no need to do that. You need the function to be persistent, not the ComputedAttribute itself. If the function is currently a pure-Python function, you need to replace it with some kind of callable object that can be pickled, such as a PythonScript. You could also write your own class to do this, but again it is not the ComputedAttribute part that would cause a problem. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: International Objects
Roger, I've identified a serious weirdness that causes InternationalObjects not to work. It's this... InternationalObjects - works on 2.4.0 and 2.4.0 upgraded to 2.4.1 but does not work on clean 2.4.1 install. This indicates an disconnect between the upgrade and clean install paths (at least that's my first thought). Zope-devers, any ideas? Anybody know of any __getattr__ changes in the 2.4.0 to 2.4.1 transition? Cheers, Tim Roger Espinosa wrote: On Wed, 17 Oct 2001, Tim McLaughlin wrote: If so, let me know what you think after you toy with it a bit. Note that it also works with ZClass props :) Still persisting, as the more I dwell on it, the more I like this approach --- one of the reasons I'm using Zope is the ease of mixing complicated code with simpler code (handy for the education environment), and this approach fits that ideal. At any rate --- I continue to fail if I try the monkeypatch; oddly, if I do this bit of code: x = Item() print Item.__getattr__(x, 'DEBUG') it'll correctly work, but x.DEBUG seems to skip it altogether; I even assigned the InternationalObjects __getattr__ to an unrelated method (e.g. Item.fetchValueForKey = __getattr__) and *that* works, which sure looks like something else is hijacking __getattr__. Except when I just go patch the code into OFS.SimpleItem (I'm already hacking get_request, so what the heck :)...it works as hoped. (Which would tend to discount the hijacked __getattr__ business.) Anyway, neat idea :) Roger -- Tim McLaughlin iterationZERO - www.iterationzero.com 703.481.2233 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
