Re: [Zope-dev] FW: ZPatterns, ObjectDomain, UML and all that.....
At 09:44 PM 12/5/00 +0200, Roch'e Compaan wrote: >> 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. > >But what if I always store dataskins in there own racks but simply assign an attribute of one >Dataskin to the instance of another Dataskin? I simply want to be able to say >Customer.Address.Street... > As implied above, you cannot, unless you do so with an appropriate provider. Just like ZODB-stored objects, ZPatterns objects cannot function if you break the rules that govern their behavior. (E.g. if you change a mutable value of a ZODB object, it has no way to know it should be saved to the database.) This is a "by design" limitation of ZPatterns. Also, it's not that bad of a limitation. You can easily work around it with SkinScript or an attribute provider, and more commonly, this is done by delegation to another specialist. Specifically, rather than breaking encapsulation by having application code write to an attribute directly, you use a method which delegates to the foreign specialist, asking it to link or create an associated object. You can then still use SkinScript to retrieve your "Address" attribute, again by delegation to the other Specialist. ___ 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 )
Re: [Zope-dev] FW: ZPatterns, ObjectDomain, UML and all that.....
> 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. But what if I always store dataskins in there own racks but simply assign an attribute of one Dataskin to the instance of another Dataskin? I simply want to be able to say Customer.Address.Street... > > > >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 I meant to say "it DOES know" - but I do NOT :) Roché ___ 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 )
Re: [Zope-dev] FW: ZPatterns, ObjectDomain, UML and all that.....
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 )
