[Zope] Pointer-to-Object Properties

[Michael Bernstein]

"Jay, Dylan" wrote:
> 
> From: Thomas B. Passin [mailto:tpassin@mitretek.org]
> >
> > From: Toby Dickenson <tdickenson@geminidataloggers.com>
> > >
> > >I think the key observation here is that the additional information
> > >should be sufficient to identify the foreign object.... then the
> > >pointed-to object can be located by searching a Catalog.
> > >
> > 
> > <stuff about SQL snipped>
> >
> > Also, you want to make keep the properties of the two types
> > of objects in the
> > many-to-many separate, to minimize coupling.  In the case of
> > books, one way to
> > do this is to have a book maintain a list of its authors, and
> > each author to
> > maintain a list of its books.  Then a book and an author only
> > need to know about
> > lists, not about authors and books.  You can delete a list
> > item without deleting
> > its parent object.  But now, if a parent object is deleted,
> > how do you make sure
> > all references to it in various lists are also deleted?  Not
> > so easy!  Back to
> > data integrity again.
> >
> > My point is really that object encapsulation and data
> > integrity are very
> > important, and it is easy to jump to a design that does not
> > provide for them.
> > If we're going to come up with a Zope-ish way let's make sure
> > its design is well
> > thought out in these areas.
> 
> What you say is very true. Zope's absence of object referencing is a big
> omission and one that makes its OO claim somewhat tenuous (along with
> independent object identity but thats another issue). As you say doing
> referencing well is quite important.
> 
> I think the current tendency to use a central ZCatalog is a good idea. Many
> to many references can be made by each object have a search criteria rather
> than a list. Then again this means the onus of inclusion is then on the
> referred to object rather than the referrer, however the deletion of either
> is ok as long as they unregister themselves from the catalog. The referred
> object will have to maintain a property/state that means it is included by
> the search.

There is a problem with letting reffered-to objects manage their
incoming pointers. It means that a user that wants one of their objects
to point to another object must either have management priveleges on the
referred object or must get another user who does to do it for him. You
could add a special permission 'Add incoming pointer' could be added to
the object and made widely available, but the equivalent 'delete
incoming pointer' permission would still have to be tightly controlled
for obvious reasons.

Hmm, I guess you could jigger things so that pointers to objects could
be managed by the owners of the referring object, even though they're
contained within the referred-to object, but that seems to be getting
needlessly baroque.

Ha! I've got it! Proposal outline and handwaving follow:

Create a bi-directional 'relationship' object (in two flavors;
one-to-many, and many-to-many) that both the referring AND the referred
object find through ZCatalog, and add a simple 'manage relationship'
permission to the referring and referred-to objects which grants them
access to it. Add a standard 'Relationships' tab to the management
interface.

Relationship objects should not be contained in either the referring or
referred to objects, and perhaps should not be visible in the management
interface at all, except through the 'Relationships' tabs of objects.

Define names and types of relationships in the ZClasses (maybe also
whether they are required or optional) as well as what Meta-types each
side of the relationship may be.

Relationship enabled objects get 'manage relationships', 'view
relationships' and other associated permissions.

In this way, objects can manage their relationships with other objects,
no user needs to have permissions on another users objects, properties
are not bent out of shape, and objects are not required to be
ObjectManagers.

What do you guys think? Would this work? Can we also get traversal to
work through the 'alias' of a relationship name?

01 (my two bits),

Michael Bernstein.