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

[yuppie]

Hi Christian!


Christian Heimes wrote:
> 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.

This is not a decision, I'm not the project owner. This is my opinion.

> 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.

PortalFolder is not just a base class, it's *the* folder class used in 
CMFDefault. Subclasses can mix in OrderSupport, but that has no effect 
on PortalFolder instances.

> 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.

That's not fair. You are free to ignore CMF development for years, but 
you can't make other people pay for that. Upgrading from 1.5.x to the 
latest 1.5 version has to work without *any* trouble.

>  > 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.

manage_renameObject is the only method that overrides Folder behavior. 
Defunct IOrderedContainer methods should not be a big problem. After all 
we are still in Zope 2 land with tons of inherited useless methods.


I'm open for any proposal that adds a *new* base class for CMF folders.

Cheers,

	Yuppie