At 03:18 PM 12/5/00 +0200, RC Compaan wrote:
a) the data manager for a DataSkin is a non-persistent attribute. (self._v_dm_). I think this means that it needs to be set somehow in every Zope transaction before you can do much of anything with the instance.
If this is the case then my current implementation will have to change quite dramatically :( I don't quite understand why Dataskins are implemented in this way - this obstructs natural object oriented programming? I would have thought that the datamanager is set when the a Dataskin is created.
Keep in mind that DataSkins are intended to be able to be *non* persistent objects, stored in a relational database, for example. And the Rack is not stored in the RDBMS. There is no conflict with O-O programming, however. In fact, this is a high-encapsulation situation. Specifically, you don't mess with the innards of a DataSkin if you're just a client of it. :) If you want to store one DataSkin inside another, where either one of them is stored in a Rack, you will have to create appropriate SkinScript or custom attribute providers to do so.
PS: I checked Rack.py:
CreateItem call _RawItem and in _RawItem the Rack for that instance is set: item._setRack(Self) # Connect to Rack
I might be wrong but after a quick look at the attributehandling code in Dataskins.py suggests that the Dataskin does not know who its datamanager is.
Yes, it does. _setRack() is called whenever a DataSkin is retrieved from a Rack. Or, if a DataSkin is stored outside a Rack, its __of__() method searches the acquisition hierarchy for a Customizer or Folder with Customizer Support in order to acquire a data manager.