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
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]
** No cross posts or HTML encoding! **
(Related lists -