[Zope3-dev] Associations

Casey Duncan c.duncan@nlada.org
Fri, 25 Jan 2002 14:03:12 -0500


On Friday 25 January 2002 12:39 pm, Gary Poster allegedly 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.

I'd say if you're waiting for people to say "put it in the fishbowl", your 
asking the wrong question. If you have to ask....

I'd say just go for it.

[snip]

> 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.

Let me give you one of my own use cases:

I have a library application where I want all documents (which are subclassed 
Zope file objs) to share a single property schema. Currently this is 
accomplished by putting all of these documents into a special "DocumentStore" 
folder which allows them to acquire the schema.

I wish to use a decentralized document storage model in the next version. 
This will allow documents in the library to be scattered around anywhere in 
the hierarchy, which is advantageous for management purposes and allows it to 
play well with the CMF. So, I have to come up with some way for the documents 
to find their schema regardless of where they might be.

The schema will be a simple object like a PropertySheet in a ZClass. You can 
define properties in it and give them an id, type and default value, plus 
arbitrary other data. When a document displays its property sheet, it will 
lookup the schema from whatever schema object is it assigned to. If you 
change the properties in the schema object, all document property sheets 
using that schema will be changed.

My solution for the time being is to just directly reference the schema from 
the documents as an attribute. When the document is instanciated, you will be 
able to pick the schema or provide a path to it. The constructor will find 
the schema object and set it in the document.

That will work except for the caveats I mentioned in my 
ExplicitObjectReferences proposal. If anybody has a better idea, I'd love to 
hear it.

> 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.

indeed.

/---------------------------------------------------\
  Casey Duncan, Sr. Web Developer
  National Legal Aid and Defender Association
  c.duncan@nlada.org
\---------------------------------------------------/