[Zope] Pointer-to-Object Properties

[Michael Bernstein]

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.