[Zope3-dev] Associations

[Steve Spicklemire]

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

On Friday, January 25, 2002, at 12:39 PM, Gary Poster wrote:

>> From: "Gary Poster" <garyposter@earthlink.net>
>> As I say at the end, I will put this up in the Fishbowl if I get
>> encouragement on it, and won't if I don't.  This is a feeler.
> <snip>
>
> The silence is deafening.  OK.
>
>> From: "R. David Murray" <bitz@bitdance.com>
> <snip>
>> If you've got data whose movement
>> would be a problem, don't allow it to be moved.  Store all the
>> objects in a btree, say, and provide an API to the rest of your
>> app for getting those objects.
> <snip>
>
> One of the reasons I moved away from ZPatterns in my planning was that 
> it
> did not match my use cases.  Unfortunately, your solution shares that
> characteristic.
>
> Requiring objects that need relations to only be stored in an isolated 
> data
> store is acceptable if you move away from a standard Zope structure, 
> but if
> you want, for instance, CMF members to be able to add objects that can
> relate and be related to, while remaining in their folders for security 
> and
> organization reasons, the solution is untenable.
>
> A solution for a basic problem like joins that requires a Zope 
> programmer to
> break the standard Zope design patterns is problematic in its own way, 
> IMO.
>
> Gary
>
>
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org
> http://lists.zope.org/mailman/listinfo/zope3-dev