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
Rik Hoekstra wrote:
[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.
Well, this gives you the ability to create, for example, 'Car' and 'Bicycle' objects, and designate them both as meta type 'vehicle', then create an 'Owner' relationship between 'vehicle's and 'Person's. A trivial example, to be sure. I suppose the relationship objects could be 'instrumented' to allow other types of filtering criteria. Whatever the criteria though, the possible objects need to be presented through a 'relationships' form within the ZClass instance.
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.
You're right, one-to-one relationships should be implemented as well, but as you noted, this proposal is not as critical to implementing one-to-one relationships as it is for many-to-many.
- 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.
That's pretty close. My proposal actually has two levels of indirection: first the relationship objects that are relevant to the ZClass are obtained from a ZCatalog like object (the relationship folder in the control panel), and then those relationship objects (themselves ZCatalog-like) are queried to obtain the objects that the ZClass instance is associated with. Then you should be able to access these objects' properties and contents as if they were contained within the current object's relationship: <dtml-in Author> <dtml-var name> </dtml-in> By doing it this way, you can add relationship types between you classes as your application grows in complexity without having to re-instantiate all your objects. All you would have to change would be the add/edit methods in the ZClass, and whatever viewing methods that you want to expose the new information (other than the relationships tab in the management intrface).
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.
Neither approach would give me the ability to refer to linked to objects as if they were sub-objects. This is critical for the simplicity of the DTML to access the associated objects' contents and properties. In short, I want a pseudo sub-object that acts as a proxy for the real object, not a symlink I can follow or resolve to access. The end result is much the same, but the semantics are radically simpler with my proposal. Note: associated objects should NOT appear within the 'Contents' tab.
- 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.
First, relationship_aware is optional; all it's absence means is that the object is not aware of it's outgoing relationships. Other relationship_aware objects could refer to it with no problem. Second, if, for example, you want a relationship_aware Folder, just subclass Folder and relationship_aware in a new ZCLass.
- 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)
I'll check it out, thanks. Michael Bernstein.
participants (2)
-
Michael Bernstein -
Rik Hoekstra