It would be very beneficial to be able to 'point' to arbitrary objects as if they were sub objects, thus enabling one-to-many, many-to-one, and many-to-many relationships not constrained by the object heirarchy.
Classic example: Many author objects, many book objects. Authors can have written several books, and certain books are collaborations with more than one author. It does not make sense for books to be contained within authors, or authors to be contained within books.
While this simplistic scenario would allow us to either assign a list property with book titles to an author object, or a list property containing authors names to a book object, and live with the small amount of duplicated data
I'd like to jump in and play devil's advocate for a moment. Note that this is not to necessarily refute the idea of pointer-to-obj properties, but more to start brainstorming and to help me get a better idea of the core problem here... Historically (or hysterically, as Jim would say) properties have had some basic traits that distinguish them from "subobjects": o They are generally "simple named values" of simple types. o Being simple types, they have either no or very limited behavior. o They have somewhat less of a sense of "identity" than full Zope objects. o They are not protected individually by the security machinery. So to summarize, properties were really designed to be supporting players rather than lead actors on the Zope stage - they should be thought of as metadata about an object more than as objects themselves in most cases. Looking at your books and authors example:
Classic example: Many author objects, many book objects. Authors can have written several books, and certain books are collaborations with more than one author. It does not make sense for books to be contained within authors, or authors to be contained within books.
The important thing in this example is the relationships, not the actual "place" of the objects. From a design perspective, the details of where the actual objects come from would be best hidden behind a set of interfaces anyway: # get a book object theBook=someMethodToGetABook() # get a list of author objects authors=theBook.getAuthors() for dude in authors: books=dude.getBooks() Having interfaces like these would give you an extensible architecture - books and authors could later come from a relational db or other source as the system grows. The core problem (it seems to me) is that Zope currently makes it hard to do the many-to-many relationships that are needed behind the scenes to implement these interfaces. Rather than do a lot of work extending the meaning and capabilities of properties, it seems to me that this could be handled if we had some sort of "reference" object. What if, for example, you could do a "copy" on an object then go to some other folder and do a "paste reference"? Assuming we had this, you could implement your interfaces over a Zope design where you have 2 Folders: "Books" contains Book objects and "Authors" contains Author objects. Both Book and Author objects would be ObjectManagers. Though a Book would never contain an _actual_ Author object directly, it could contain any number of _references_ to Author objects and vice versa. A Book object's getAuthors interface returns a list of Author objects - these could be obtained either by sorting through objectValues on the Book itself or, better yet, each Book may have a Folder "Authors" which it uses as a collection to store Author references. Such a design would (IMHO) have a number of advantages over going the property route. You would have much more flexibility in designing your system because you could traverse right through a book into its author, use acquisition and all the other benefits of the containment heirarchy. Perhaps most importantly, you would have fine-grained access control over the objects (properties would be all-or-nothing). While there would be some issues to work through in implementing reference objects, I suspect it would be much less than would be required to make properties meet your needs. There is also some amount of prior thought that has gone into this; the IETF WebDAV working group has been working on a "bindings" spec and they have a pretty decent object model that has come out of dealing with all of the issues of bindings/references. I've found that model to be a good place to start when thinking about bindings in Zope. Well, I've rambled on long enough - let me know if any of this has the ring of truth to you or if you think I'm totally missing the point... Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
You got me thinking... that's a good thing, right? :) Brian Lloyd wrote: [snip]
I'd like to jump in and play devil's advocate for a moment. Note that this is not to necessarily refute the idea of pointer-to-obj properties, but more to start brainstorming and to help me get a better idea of the core problem here...
Historically (or hysterically, as Jim would say) properties have had some basic traits that distinguish them from "subobjects":
o They are generally "simple named values" of simple types.
o Being simple types, they have either no or very limited behavior.
o They have somewhat less of a sense of "identity" than full Zope objects.
o They are not protected individually by the security machinery.
So to summarize, properties were really designed to be supporting players rather than lead actors on the Zope stage - they should be thought of as metadata about an object more than as objects themselves in most cases.
You've left off one *really* useful practical application of (Z Class) properties. They're *guaranteed* to be there, at least, with their default values. The lack of this ability with full-fledged objects isn't quite the same domain as the book/author problem, so I digress. :) (Plus, there are work arounds that may not be pretty, but they work.) [snip]
Rather than do a lot of work extending the meaning and capabilities of properties, it seems to me that this could be handled if we had some sort of "reference" object.
[snip] You've just hit the nail on the head. The perfect solution to provide the feature you want here is XLink, http://www.w3.org/TR/1998/WD-xlink-19980303. This spec describes how to use XML to express any kind of relationship between any number of objects. They can be embedded in one of the objects (inline), like HTML <A> tag, or they can be "out of line" and point to several objects. It's easy to envision a Z Class based on XML Document that is simply an XLink. Zope with Z Catalog gives server side framework to make XLink work until all browsers support it. Simply create a Z Catalog that only indexes the links and their properties, suddenly it's easy (and fast!) to find out things like "who points to me?" In terms of your example, 'theBook.getAuthors()' would query the link catalog for links that referenced theBook with the 'role' of 'author' (*). The XLink implementation details wouldn't matter... o the link could be coming from an Author object pointing to this book o from an out of line link that associated the two 0 or even an inline link at the book's end (*) See the spec on more information on roles. Basically each locator can be associated with a role... which is not defined by the XLink standard but by standards based on XLink, i.e., everyone has to agree what a role of 'author' means. Take the more interesting example of annotating a document. Each document could provide a "Annotate" link at the bottom (along with "Printable Page" :) that allows the browser to comment on the document. When I click on that link a new XLink is created in my "home" directory and I add my comment. It automatically gets cataloged in the link catalog. Now that there is an annotation, a "View Annotations" link appears and everyone can click on that to see the annotation. That document is simply generated by displaying all the links of role 'annotation' in the link catalog. XLink (really XPointer) provides a way to link to specific parts of a document, so ideally an annotation could be attached to a specific paragraph. Then when the document is rendered, there is an HTML <A> tag at the appropriate place to display the comment. It would even be possible to show the annotation as a sidebar at the appropriate place. (Note: the link itself contains the body of the annotation... see the Annotated XML Standard, http://www.xml.com/pub/axml/axmlintro.html, for another implementation of annotation using XLink.) The one drawback is that (right now) I don't think Z Catalogs can index parts of objects. This limits the usefulness of inline links in XML documents. Are there any technical limitations to the design (of Z Catalog or XML Document) that would prevent this from being possible?
Well, I've rambled on long enough - let me know if any of this has the ring of truth to you or if you think I'm totally missing the point...
I think I've rambled on enough, too. :) Please tell me if this makes any sense to someone other than me. It may be necessary to read (or at least scan) the XLink (and possibly XPointer) standards to grok what I'm thinking. -Otto.
Brian Lloyd wrote:
I'd like to jump in and play devil's advocate for a moment. Note that this is not to necessarily refute the idea of pointer-to-obj properties, but more to start brainstorming and to help me get a better idea of the core problem here...
Understood, thanks for the input...
Historically (or hysterically, as Jim would say) properties have had some basic traits that distinguish them from "subobjects":
o They are generally "simple named values" of simple types.
o Being simple types, they have either no or very limited behavior.
o They have somewhat less of a sense of "identity" than full Zope objects.
o They are not protected individually by the security machinery.
So to summarize, properties were really designed to be supporting players rather than lead actors on the Zope stage - they should be thought of as metadata about an object more than as objects themselves in most cases.
Exactly. Thanks for the clear summary.
Looking at your books and authors example:
Classic example: Many author objects, many book objects. Authors can have written several books, and certain books are collaborations with more than one author. It does not make sense for books to be contained within authors, or authors to be contained within books.
The important thing in this example is the relationships, not the actual "place" of the objects. From a design perspective, the details of where the actual objects come from would be best hidden behind a set of interfaces anyway:
# get a book object theBook=someMethodToGetABook()
# get a list of author objects authors=theBook.getAuthors()
for dude in authors: books=dude.getBooks()
Having interfaces like these would give you an extensible architecture - books and authors could later come from a relational db or other source as the system grows.
The core problem (it seems to me) is that Zope currently makes it hard to do the many-to-many relationships that are needed behind the scenes to implement these interfaces.
With you so far.
<description of references as contained objects snipped>
Such a design would (IMHO) have a number of advantages over going the property route. You would have much more flexibility in designing your system because you could traverse right through a book into its author, use acquisition and all the other benefits of the containment heirarchy. Perhaps most importantly, you would have fine-grained access control over the objects (properties would be all-or-nothing).
While traversing into referenced objects is attractive, acquisition in this case is a two-edged sword. If authors ordinarily acquire a method or property from somewhere 'above' their actual location, traversing into an Author from a Book could cause the Author to acquire the wrong method or property. Extending properties to allow traversal into a referenced object appears to be a convenient breakpoint for disengaging acquisition and security. We do not necesarily want someone with manager access on a Book to be able to change an Authors contact information. Since the management interface supports the basic model of 'customers who have customers', breaking this model for the sake of many-to-many relationships seems a poor trade-off. I would think that by going the properties route, all security settings would derive from the objects context within it's actual location, and that the referencing objects context would be completely inapplicable. How is this issue going to be handled with the proposed Topics? Topic objects are supposed to present an 'alternate' containment heirarchy, will they allow overiding a contained object's security settings?
While there would be some issues to work through in implementing reference objects, I suspect it would be much less than would be required to make properties meet your needs. There is also some amount of prior thought that has gone into this; the IETF WebDAV working group has been working on a "bindings" spec and they have a pretty decent object model that has come out of dealing with all of the issues of bindings/references. I've found that model to be a good place to start when thinking about bindings in Zope.
I'll check it out.
Well, I've rambled on long enough - let me know if any of this has the ring of truth to you or if you think I'm totally missing the point...
I don't think you're missing the point, and I found your input to be very valuable, but I don't think that Acquisition is always a Good Thing. Michael Bernstein.
Michael Bernstein <mbernstein@profitscape.net> wrote:
How is this issue going to be handled with the proposed Topics? Topic objects are supposed to present an 'alternate' containment heirarchy, will they allow overiding a contained object's security settings?
No. Actually, they don't contain objects. They work by canning a set of ZCatalog queries. The object the queries result in after being ANDed together are the objects that are 'in' the ZTopic, but 'in' only in a figurative sense. They can contain more ZTopics, though, and the ZTopics they contain can serve to refine the searches to provide topical hierarchies. It's really neat. Mike.
participants (4)
-
Brian Lloyd -
Michael Bernstein -
Mike Pelletier -
Otto Hammersmith