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