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