adding properties to instances v. classes
There's this somewhat annoying issues surrounding objects that declare removable properties in their classes, in that if you remove them, you can't add them again because many times a class variable of the same name already exists. (atleast thats my understanding of it, I suppose I could be smoking something) The issue was raised in bug 337 which was subsequently closed after the Image class got a slight massaging. I'm wondering if there's any reason why simply adding the properties and instance variables to the instance within __init__ would be a bad thing for properties that you want to declare removable. For example: class Baz(Stuff): """meh.""" title = '' _properties = ({'id':'title', 'type': 'string', 'mode':'w'},) def __init__(self, id, title, foo): self._properties += ({'id':'foo', 'type':'string'},) self.foo = foo self.title = title ... Seems like it would be a fairly easy fix and it certainly seems to work, am I missing something? I'm also wondering what the deal is with the title property, should it alway be removable, always be unremovable, or always be what you want it to be depending on your mood ring? It doesn't seem like there's a great deal of consistency and I'm wondering if thats intentional. -- Jamie Heilman http://audible.transient.net/~jamie/ "It's almost impossible to overestimate the unimportance of most things." -John Logue
Jamie Heilman writes:
... I'm wondering if there's any reason why simply adding the properties and instance variables to the instance within __init__ would be a bad thing for properties that you want to declare removable. The restriction is a precaution against an accidental overriding of essential infrastructure.
Think, when someone creates of property with the name "manage_main" or "manage_workspace". Or when he create a property with the same name as a content object. What should happen? An additional declaration might help, something like "_addableProperties". Names specified in this sequence could be allowed as property names unless the instance (itself) already has an attribute of this name. Of course, something like this needs to be implemented and is currently not available. Dieter
An additional declaration might help, something like "_addableProperties". Names specified in this sequence could be allowed as property names unless the instance (itself) already has an attribute of this name. Of course, something like this needs to be implemented and is currently not available.
OK, let me offer a specific example, currently the height and width properties of an Image object are removable from the ZMI. If you do that though, you can't add them back. Its sorta silly. What I was about to play with was simply removing the the height and width class variables from the Image class and replacing where they are initially set up and modified when a new image is uploaded in udpate_data(), with something like: if width >= 0 and height >= 0: if self.hasProperty('width'): self.manage_changeProperties(width=width) else: self.manage_addProperty('width', width, 'string') if self.hasProperty('height'): self.manage_changeProperties(height=height) else: self.manage_addProperty('height', height, 'string') Unless I'm missing something, which is entirely possible, I haven't tested this yet and I'm about to go to bed so I probably won't until sometime tomarrow, but I think this might let height and width properties be freely removed and re-added without any bad side effects. I'll probably have to kick the tag() function some to make it transparent, but that seems to be typical as the tag() function is just something of an impurity. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy
... currently the height and width properties of an Image object are removable from the ZMI. If you do that though, you can't add them back. Its sorta silly.
Well, after fiddling with it a for a while I've decided I never want to open Image.py ever again, that code is just too far gone. I did get the effect I desired working, in that I could remove the height and width properties and when I did the tag() routine didn't include those attributes in markup anymore, plus I could add them back. It broke compatibility with image objects already in the zodb though so its probably of no help to anyone. -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa
participants (2)
-
Dieter Maurer -
Jamie Heilman