[Zope3-dev] Associations

[Steve Spicklemire]

Hi Phillip!

	Yes.. except a "standard" DataSkin needs either a Rack or a Folder 
w/Customizer Support to act as a data manager. It would be nice if the 
application could provide a service "getDataManagerForType" so that 
standard DataSkins could be created anywhere, e.g., in a "default" CMF, 
without needing to do anything special, other than implement 
"getDataManagerForType" which could easily return a Rack. Hmm... could I 
just subclass DataSkin and implement __of__ to call an acquired 
getDataManagerForType to set the DataSkin's _v_dm_?

-steve

On Tuesday, January 29, 2002, at 08:56  AM, Phillip J. Eby wrote:

> At 12:55 PM 1/25/02 -0500, Steve Spicklemire wrote:
>> Hi Gary,
>>
>>         What if we had a "Component-DataSkin-proxy". An object that 
>> could live anywhere in a "Component" based site, pose as e.g., 
>> PortalContent, but that was actually a proxy for a DataSkin instance 
>> stored in a rack somewhere. You could move the proxy anywhere you like 
>> without breaking the "proxy-dataskin" relationship. The proxy could 
>> delegate all getattr/setattr to it's dataskin/datamanager. This way 
>> you could keep all the data independence of ZPatterns, and still use 
>> Component Model ideas.
>>
>> Does that make any sense?
>> -steve
>
> Actually, Steve, you've just described a standard ZPatterns DataSkin, 
> in the sense that you can subclass DataSkin to add whatever methods you 
> need, and any DataSkin can be proxied to other DataSkins or directly to 
> data, by writing the appropriate SkinScript.  So there isn't even 
> anything extra to implement, there.
>
> The same pattern can be implemented in TransWarp, since Domain objects 
> can Dispatch many-to-many to Data objects.  (i.e., many Domain objects 
> can share the same Data object, and a Domain object may map to more 
> than one Data object).