[Zope] beginner's question: references
Rik Hoekstra
rik.hoekstra@inghist.nl
Fri, 17 Mar 2000 10:10:30 +0100
> 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,
[RH]Michael,
What you seem to be descibing is some sort of an internal Zope 'link base'
as they exist for may hypertext systems (but zopish). This would be very
useful.
I do have some doubts about your desciption, however:
- would the generic relationships (meta-type<->meta-type) you describe be
the best way to go and whether they would turn out to be very useful. You
also do not mention one-to-one relationships; I'm sure this is not on
purpose, but this could be implemented quite simply by a specific python
product.
- I also wonder whether much of what you describe cannot also be achieved in
other ways, mainly through using the Catalog (as you indicated yourself). If
I may speculate a bit more on this point: what you want may be a specialized
folder index method that uses a mix of its own objectValues and Catalog
obtained objectvalues for its contents. If you wanted to use symlink type
relations, this may be done by using properties (this is more or less
generic) or by using the values of a 'link base' type of object (see above).
THis last would be very specific: pointing to specific objects.
- The idea of relationship aware is nice, but the drawback is that it can
only be true for derived ZClasses, and not all zope objects are Zclasses.
- In ZDP list many of these subjects have been in question for some time
now. You may want to have a look at the list archives of last month for many
of the discussions and of course the implementation of ZDP Tools by Maik
Roeder (available somewhere from his member page:
http://www.zope.org/Members/roeder)
Rik