Michael Bernstein wrote: [snip]
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.
I think we're on the same track, see my XLink ramblings from yesterday: http://lists.zope.org/pipermail/zope/1999-November/013235.html This is preceisely the kind of thing XLink was designed to solve. There are a few reasons for using XLink syntax rather than rolling our own... * The W3C working group has done all the thinking about what these kinds of links should be able to do. * It's a standard (still draft, but it will be final eventually :). * When browsers support XLinks (Mozilla does a little) you can just expose your XLink data to the browser and let it do what it wants with them. (Read up on link collections in the spec to see what you could do with a catalog full of links and an appriately formed header on an XML document.)
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.
Out of line links! The Relationships tab could be there for classes that are aware of their (incoming and outgoing) links just so you can see these things in the management interface.
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.
This is basically handled by the role attribute on XLink locators. They don't dictate what kind of objects can be pointed to, but I don't really see the advantage of that. The important part is agreeing on the semantics of a role (i.e., what 'author' means)... if you happen to point to an object that understands what that means, great, if not then someone else probably does and wants that information.
Relationship enabled objects get 'manage relationships', 'view relationships' and other associated permissions.
A convenient way to write/edit XLinks. I like it. :)
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.
You just summed up the purpose of out of line links. :)
What do you guys think? Would this work? Can we also get traversal to work through the 'alias' of a relationship name?
I like it. And, yes it would work. I'm not sure I understand your third question. (BTW, please tell me if my ramblins make any sense or not, thanks. :) -Otto.