The patch I propose to include is:
Could some Plone folks please test that switching to
CMF/branches/efge-1.5-five-compatible instead of CMF/branches/1.5 doesn't
cause problems in Plone ? This patch just changes the order of base class
for File and Image, and to do the CMFCatalogAware recursion it calls its
base class instead of redoing it by hand.
Florent Guillaume wrote:
To make sure that CMF 1.5.5 will play well with Five 1.2, I have to
make sure that no method manage_afterAdd redoes a recursion that one of
its base classes was doing, as we have to be prepared to have the base
class monkey-patched to use events, and have recursion done with events.
Concretely, today CMFCatalogAware.manage_afterAdd does full recursion
"by itself" in the children.
To fix that, I would have to make CMFCatalogAware.manage_afterAdd
delegate to its base class to do the recursion on non-opaque objects.
But CMFCatalogAware is a mixin class, so the only way I'll do what I
want is by using super(). Of course as you know, if you use super()
somewhere you have to use it everywhere, otherwise Bad Things happen
So I'll have to change the users of manage_afterAdd & co in CMF to use
super() correctly. Because some base Zope classes don't user super (), I
have to reorder some classes.
Namely, File and Image classes will have to be changed so that
CMFCatalogAware is before OFS.Image.File in the bases. Plus some
additional details to make getId() work.
Does someone have a problem with me doing that in the CMF 1.5 branch?
All with tests of course.
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests