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. _______________________________________________ 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 )
