From: Paul Winkler [mailto:pw_lists@slinkp.com]
On Thu, Oct 09, 2003 at 08:46:24PM -0700, Jason Corbett wrote: How does an object in zope know where it sits in the hirearchy,
The only unique identifier that zope provides is the containment path. An object can tell you its containment path by doing foo.absolute_url(1) or foo.getPhysicalPath() depending on what form you want the output in.
I am often confused by this as well. I think, however, that you can also reach objects by its "object id" oid. If I just use simple assignment of a variable to an object in Zope, I get that object's oid, right?
On Fri, 2003-10-10 at 05:51, Bjorn Stabell wrote:
From: Paul Winkler [mailto:pw_lists@slinkp.com]
On Thu, Oct 09, 2003 at 08:46:24PM -0700, Jason Corbett wrote: How does an object in zope know where it sits in the hirearchy,
The only unique identifier that zope provides is the containment path. An object can tell you its containment path by doing foo.absolute_url(1) or foo.getPhysicalPath() depending on what form you want the output in.
I am often confused by this as well. I think, however, that you can also reach objects by its "object id" oid. If I just use simple assignment of a variable to an object in Zope, I get that object's oid, right?
Yes, but only at the ZODB level, and only if the "contained" object derives from Persistent. From the application's point of view, OIDs are irrelevant and useless: there is no API for manipulating them sanely. For example: from OFS.SimpleItem import SimpleItem # derives from Persistent class Foo( SimpleItem ): pass owning = Foo() owned = Foo() owning.owned = owned While it is true that the ZODB will pickle only the OID of 'owned' within the dict of 'owning', the application doesn't need or want to manipulate the OID, because it can just refer to 'owning.owned'. This kind of reference is conceptually like a "hard link" in a traditional Unix filesystem; the same "file" can be stored in multiple "directories", because the directory contains only a mapping of filename to "inode" (OID). The analog for a "symlink" would be to store a path to the object, and then use '{,un}restrictedTraverse' to fetch the object when needed. There are a number of products available which try to make such "symlinks" more transparent to the application; it is, however, harded to make this work cleanly in the general case. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
Hi Jason, if you want to deal with references and unique ids and that stuff, feel free to take a look at http://plone.org/development/current/projects/Ticle and perhaps to contribute your ideas or even sourcecode. -sp
participants (3)
-
Bjorn Stabell -
Simon Pamies -
Tres Seaver