[Zope] Pointer-to-Object Properties

[Thomas B. Passin]

From: Michael Bernstein <mbernstein@profitscape.net>
Subject: Re: [Zope] Pointer-to-Object Properties


>"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?
>...
>Michael Bernstein.

Any kind of "list" or "catalog" or "bidirectional relationship object" should be
an object of its own, not  property of another object.  If we stick with books
and authors for the sake of a concrete example, we could
1) subclass book and author to add a reference to the catalog/relationship; or
2) let the catalog/relationship hold object references to its books and authors;
or
3) let the catalog/relationship hold ids or names (as opposed to pointers or
object references) to its books and authors;

Now let's walk through some things we might like to do:
A) Find out the authors of a given book
    1) Ask the book to ask the catalog/relationship for its authors.
    2) Find which catalog/relationship holds references to our book, then ask it
for the corresponding authors.
    3) FInd which catalog/relationship refers to the title or id of our book,
then ask it for the corresponding authors.

B) Add a new book to the list of books written by a particular author
    1) Ask the author for its catalog/relationship of books, then tell the
catalog/relationship to add the new book.
    2) Find which catalog/relationship holds references to our author, then tell
it to add the new book, linked to our author.
    3) Find which catalog/relationship refers to the name or id of our author,
and tell it to add the new name or id of the book, linked to the id or name of
our author.

We also need to think out whether a book should know its authors or an author
should know its books.

Now everyone else, help me out here!  How do these scenarios relate to the
permission and acquisition questions people have raised?  For 2) and 3), how do
we find the catalog/relationship in the first place to get started with the
search?  What other important and different scenarios need to be considered in
the context of Zope?

While we're at it, remember that an object might participate in numerous
many-to-many relationships, which might rule out approach 1).

Who would like to add their thoughts?

Tom Passin