FW: ZPatterns, ObjectDomain, UML and all that.....
(forgot to cc this to zope-dev) -----Original Message----- From: RC Compaan [mailto:sparroy@adept.co.za] Sent: 05 December 2000 03:17 To: steve@spvi.com Subject: RE: ZPatterns, ObjectDomain, UML and all that.....
Thanks... is that working between transactions? It has me a little confused. I've been snooping through the implementation of ZPatterns for a clue.... and it looks to me like:
Well so far it seems to work fine... I do however receive a KeyError with one of my Dataskins but this is isolated to one particular Dataskin. I did not inspect the innards of ZPatterns that well, I must say, so this issue still remains unresolved to me as well.
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.
RC> With Container/Content type objects I do roughly the same - I RC> have setContainer methods for the Content objects.
So most of your objects are defined in Python products, or are these methods ExternalMethods?
They are all external methods - I do most of my development with ZClasses and Python Methods make life a lot easier. Roché 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.
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.
participants (2)
-
Phillip J. Eby -
RC Compaan