PLIP 168 feedback (and fixes) was Re: [Framework-Team] Re: PLIP review overview

Tom Lazar lists at
Thu Dec 28 00:17:47 UTC 2006

On Nov 18, 2006, at 11:43 PM, Tom Lazar wrote:

> there is still one issue that needs to be addressed IMHO. i've also  
> filed an issue for that:
> basically, it means that references to children of an iterated  
> folderish object are broken after that object is iterated. kapil  
> has postponed that issue and i can understand that that's a really  
> tough cookie to solve generically but this somehow needs to be  
> addressed if we want to ship plone with iterate! if we can't fix  
> the issue we should at least prevent a COCI-cycle for folderish  
> objects that contain children with backreferences. any other  
> suggestions?

just a 'heads up' that i meanwhile have addressed this issue and have  
created a working patch which i hereby humbly offer for review... :)

for convenience, here's the contents of the issue:

Currently, when (a) checking out an object it (and all its children)  
lose all their references (this is done by Archetypes implementation  
of paste on copy, which iterate utilizes to perform the checkout).

Additionally, (b) upon checkin, all backreferences get lost, i.e. any  
content that references the iterated object (or any of its children)  
will end up with broken references upon checkin.

Kapil has signalled, that he has plans to remedy this, by simply  
recording all changes made to the working copy and then apply these  
to the baseline upon checkin, thus avoiding the messy issue of  
'swapping identities' entirely. however, he also signalled, that this  
implementation is still a bit further off and also, this wouldn't  
address case (a).

i have therefore created a patch for the 0.3 branch that attempts to  
resolve (a) and (b). upon checkout the baselines forward references  
are recreated for the working copy and upon checkin the  
backreferences are recreated.

again, i haven't written any tests for iterate itself, but have ample  
test coverage using custom content types for the client project that  
this patch was created for. if the patch is approved in principal, i  
can easily port them to iterate for default ATCT types.

what's still missing (as i just realize) is recursive locking of the  
baseline's children upon checkout, but that can easily be remedied.

the patch is rather simple, actually and i hope it might prove to be  



More information about the Framework-Team mailing list