[Zope] beginner's question: references

[Michael Bernstein]

Michel Pelletier wrote:

> You mean references?  We've thought about this problem a little and Jim
> and I discussed this over Chinese buffet once, I obviously had less of a
> clue than him, but I belive the result of our discussion is that there
> should be some sort of standard for one Zope object to refer to
> another.  The simplest way we could think of is simply storing the
> path.  Such as:
> 
> attribute = "../../relative/path/to/other/object"
> 
> or perhaps:
> 
> attribute = '/absolute/path/to/object'
> 
> Then when you want the object you ask Zope to resolve that path for
> you.  Currently you can use REQUEST.resolve_url(attribute) to do that
> for you.
> 
> If you're not working on python you can simply set a string property as
> the path.
> 
> This is how ZCatalog does it (actually ZCatalog uses a slightly dumber
> version of this concept, don't ask).  HOWEVER, the lack of any kind of
> standard or support for such references in the framework has bitten
> ZCatalog (and webdav) in the past, and the decisions we made will
> probably come back to haunt us real soon now.  You have been warned.

I've been asking for this sort of capability for about a year now (I
even offered to cough up real money to get it in) and got nowhere.

Tha last time I brought this up was in November
(http://lists.zope.org/pipermail/zope/1999-November/013362.html), but
I've refined what i think needs to be done a bit, bear with me because
it's still a little fuzzy (I'm aware that the following proposal has
some serious handwaving in it):

Zope needs a new folder in the control panel (call it 'Relationships')
that contains 'Relationship' objects.

'Relationship' objects come in two flavors: one-to-many, and
many-to-many. you define what meta types are allowed on either side of
the relationship in it. All relationships are bi-directional.


ZClasses that subclass 'relationship_aware' get a new tab labeled
'Relationships', which is automatically populated with any
'Relationship' objects that it finds. appropriate 'edit' methods should
be automatically generated.

in the ZClass instance, Relationships should behave much the same as
property sheets, except that you can traverse them to get at the
properties of the objects on the other side. The trick is, the
information about the relationship between two objects is not maintained
in either of them, but in the 'Relationship' object instead.

Example:

Two Zclasses are built, called 'Book' and 'Person'. Both subclass
'relationship_aware'. an 'Author' Relationship object (many-to-many) is
added to the 'Relationships' control panel folder. The 'Author'
Relationship allows object of meta type 'book' on one side of the
relationship, and objects of meta type 'Person' on the other.

Now you go back to the 'Book' and 'Person' ZClasses, and under the
'Relationship' tab you generate add/edit methods for the 'Author'
Relationship that the ZClasses can now discover.

As you may have noticed, both the 'Relationships' Folder and the
'Relationship' objects it contains bear some resemblance to ZCatalog.

Because we defined the 'Author' relationship to be many-to-many, 'Book's
can now have multiple  'Person's associated with them and 'Person's can
have multiple 'Book's.

Ideally you would now be able to do this after having set the neccessary
associations within the ZClass instances:

from within a 'Book' index_html method:

Written by:
<dtml-in Author>
<dtml-var name>
</dtml-in>


And from within a 'Person' index_html method:

<dtml-if Author>
<dtml-var name> has written:
<dtml-in Author>
<dtml-var title>
</dtml-in>
</dtml-if>

We can elaborate on this model to allow 'Person' objects to also be
associated with a 'Book' through an 'Editor' relationship, allow
'Person' objects to be associated with each other through an
'in_rolodex' relationship, etc.

This approach has various advantages, not the least of which is that
because neither object is responsible for maintaining the relationship
information, you don't have to worry too much about what happens when
one of the objects is deleted.

Another is that if one object sets the association up, the object on the
other side of the relationship is immediately aware of it as well (as
long as it too is relationship_aware). My favorite advantage is the
simplicity of the DTML that results from the named relationship being
traversable.

Let me know what you think,

Michael Bernstein.