[Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder

[Christian Heimes]

yuppie wrote:
 > First of all CMF 1.5.2 has to be backwards compatible to CMF 1.5.0 and
 > 1.5.1, so reverting that change is no option.

That is understandable from your point of view but I don't agree with 
the desicion. The new ordered PortalFolder has deep impacts on software 
that exists for years and depend on PortalFolder to be a subclass of 
Folder w/o order support. This includes BTreeFolder2, Archetypes and all 
Archetypes based products. Archetypes distinguishes explictly between 
BaseFolder and OrderedBaseFolder.

I'm proposing to change PortalFolder in the following way:

  * Revert PortalFolder to be subclassed from Folder

  * Create an OrederedPortalFolder as subclass from OrderedFolder

  * Subclass all classes in CMF from OrderedPortalFolder instead of 
PortalFolder

All third party software that was working with CMF 1.4 and older would 
work as expected and all CMF core software would still use the ordered 
folder. The downside is that software written for CMF 1.5 has to be 
altered. But it is much easier to alter a few lines in some products 
than trying to get rid of the ordered stuff in PortalFolder.

 > I propose to override manage_renameObject in PortalFolder with code
 > that works for OrderedFolder *and* CMFBTreeFolder.

That's not enough. Existing software like Archetypes depends on 
PortalFolder to be an ordinary folder, too.
Second you have to make sure that CMFBTreeFolder doesn't implemement to 
ordered interface. As you probably know BTreeFolders aren't orderable 
per se. The patching of PortalFolder won't solve these issues.


 > BTW: I'm not at all happy with the fact that Zope 2.8 ships with
 > CMFBTreeFolder. That circular dependency is a pain to maintain. Maybe
 > we should move CMFBTreeFolder to a CMF product.

Sounds like a plan but keep in mind that other software depends on the 
import path of CMFBTreeFolder.

Christian