PLIP 168 feedback (and fixes) was Re: [Framework-Team] Re: PLIP review overview
lists at tomster.org
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
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