Dieter, Once again, thanks for the good points. Obviously one wouldn't want to create a catalog index on an attribute that just stored references ... that'd be kind of silly, and I'm sure I'd know better :) Security is pretty obviously a concern. As for acquisition, I guess the traversal would happen from the actual object's (Being referenced) point in the tree, not the reference ? (Not that I'd rely on that, I'm just curious at this point). As for Zope 3, yeah well I keep on eye on the development there, but I'm pretty much planning for the worst and a complete review of my code for it anyways, taking full advantage of the new design philosophies in it. (Just planning for the worst mind you). Acquisition has great benefits I must admit. What's always left me ... second-guessing ? the concept, is the acquisition of attributes ... THAT can be quite offputting sometimes. Acquiring objects along the tree however is great, and simplifies incredibly the effort of reducing dupplication of logic or content. In fact, removal of acquisition alone will mean reviewing our site(s) because we depend on it to share content (Move shared content up the tree to the closest common denominator). All in all I'm pretty sure those that use it would like to keep it (At least in some form). I'd suggest since someone from Zope corp is reading, that this should be a feature that stays, but with manager control. The administrator could turn on or off global acquisition, select what gets acquired (instances vs attributes) and how, and so on ... Besides I vaguely recall reading that there will be *some* acquisition available, but much more restricted in nature ? I have to guess someone will eventualy add a context wrapper that DOES do it anyway, even as a third party ? Thanks, J.F. -----Original Message----- From: Dieter Maurer [mailto:dieter@handshake.de] Sent: Saturday, February 07, 2004 7:42 AM To: Jean-Francois.Doyon@CCRS.NRCan.gc.ca Cc: zope@zope.org Subject: RE: [Zope] Persistent references to persistent objects ?!?! Jean-Francois.Doyon@CCRS.NRCan.gc.ca wrote at 2004-2-6 16:55 -0500:

Hmmm interesting point. I suppose a basic rule of thumb would be that the reference should never be stored directly as an attribute of a folderish type ?

I can imagine many useful scenarios where keeping references to objects can be very handy (Versioning, workflow, lists of objects, etc ...) ... Although I have to admit the symlink think had never really even occured to me. I'd imagine instead maintaining a list of references for instance, maybe stored as an attribute of some other non-folderish type ... you know maybe build some content-type class that, as part of it's functionality, keeps references to objects ? This should make it safe from any unexpected behavior like the one you describe, right ?

I do not think so. You must be prepared that objects retrieved via persistent references maintained by yourself behave differently than those maintained by the "standard" references. Watch out for any situation where the acquisition context is relevant: e.g. indexing, security, locating of central resources (like "MailHost"), ... Taking enough care, you will probably be able to cope with the situation. Your type of usage may be affected by Zope 3. Zope 3 has abandonned acquisition (called "context wrapper"s in Zope 3 terms) (personally, I am sad about this; "acquisition" has been one of my major selling points for Zope). In Zope 3, objects contain a reference to their parent in the hierarchy. This means that objects know their place in the hierarchy which may make it easier to have references to them in various places. -- Dieter