[Zope-dev] FW: ZPatterns, ObjectDomain, UML and all that.....

[Phillip J. Eby]

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.