Otto Hammersmith wrote:
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
Hmm. thanks for the pointer, I missed it first time 'round. The XLink spec was VERY interesting reading. Mostly it seems as though it deals with how to express (render) in XML the type of non-hierarchical structures we're discussing, and provides a good source for use-case scenarios. The question remains "How do we implement this data in the ZODB and management interface?".
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.)
Well, while exposing XLink-type information to the client as an excellent goal, and should certainly be taken into (very serious) consideration, I am more interested at the moment with making this type of information available to server-side applications.
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.
This was the most interesting part of the XLink spec for me, in that it validated a notion percolating through my brain that objects do not neccessarily have to be aware of their incoming links at all. Implementation-wise, this means that only Classes and objects that inherited from a 'relationship-aware' base class would display the 'Relationships' tab 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.
Well, you're correct that the client-side applications you're thinking of do not require this sort of feature. However, for an web interface that allows you establish these relationships (ie: create XLinks) implementing an 'Object picker' that is constrained by the object's meta-type is fairly important, and should not have to be re-implemented from scratch for each application. Putting the constraints in the Relationship Object instance seems like a convenient location.
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.
Ok, this is a Good Thing.
I'm not sure I understand your third question.
Let me give an example of what I mean: In the DTML of the default method for a book object that has a defined relationship called 'Author' to a 'Person' object (which has a 'FullName' string property), I would like to place a DTML snippet that said <dtml-var Author.Fullname> and have the final document render the pointed-to object's 'FullName' property, even if the 'Book' object has one as well(unlikely) or could acquire one from somewhere (possible). The chief advantage to containing 'pointers' within the objects themselves is that it makes implementing this easier (Re: http://lists.zope.org/pipermail/zope/1999-November/013215.html).
(BTW, please tell me if my ramblins make any sense or not, thanks. :)
Yes, you make a lot of sense, and when more browsers are XML aware, the XLink syntax will be very important for moving some of this stuff onto the client, instead of leaving it all on the server. On the other hand, this might be even more important in the interim when considered in combination with XML-RPC for moving more complex data between servers. (cue blue sky music). 01 (my two bits), Michael Bernstein.