[Zope3-dev] zope.app.uniqueid question

[Martijn Faassen]

Stephan Richter wrote:
> On Tuesday 31 August 2004 12:15, Martijn Faassen wrote:
> 
>>What I'd like is a unique id facility which can track an object with a
>>unique id even if it moves to a different container or gets renamed. So,
>>it is always possible to retrieve an object even after people cut and
>>paste it elsewhere. Is zope.app.uniqueid guaranteed to do this? At first
>>I thought it isn't, but now I'm not sure anymore what it does. It only
>>tracks ObjectAdded events, which are only sent if a new object is added
>>(or at least an object with no parent).
> 
> 
> As you mentioned below, the object reference is stored in the utility; 
> therefore it will survive moves and renaming.

Cool. The implementation was so simple I was wondering for a while, but 
it's pretty cute. :)

>>Anyway, my hidden goal is to backport this to Zope 2 as part of Five,
>>but that seems tricky, as the uniqueid utility stores objects directly
>>which it then returns, while in Zope 2 these objects would need to be
>>returned in their proper acquisition context, lacking __parent__ links
>>and the like..
> 
> 
> Yes, this seems kind of hard. Maybe you want to write an alternative 
> implementation that stores the path, but listens to all the object events to 
> correct the path, if the object is being moved, renamed, copied or whatever.

One idea I had is that actually *setting* the path on the object itself 
after each add may be a reasonably cheap trick to get around it; Five is 
already using that strategy for other reasons. Hmm..

Of course we'll need support for local utilities in Five before we can 
work on this..

Regards,

Martijn