[Zope-dev] Re: Ordered Folder again

[Florent Guillaume]

Yuppie wrote:
> Florent Guillaume wrote:
> 
>> I'm sorry to revisit an problem that I see has been discussed to death 
>> last month, but I'd like to propose a change to what has currently 
>> been checked in about Ordered Folders into Zope 2.7.
> 
> 
> No problem. Welcome to the discussion :)
> 
> 
> FYI, this is what Brian wrote off-list in reply to my last posting:
> 
>> I could only ok changing the standard Folder if the changes were 100% 
>> backward compatible (and ignorable by people who don't care) in all 
>> ways: data compatibility, api compatibility, ui compatibility.
>>
>> If nothing else, I can't see how to maintain ui compatibility, and 
>> given that lots of people currently have to override manage_main, it 
>> seems like it would be hard to come up with a solution that didn't 
>> require other product developers to do something to keep up.
>>
>> But I could certainly be wrong :) Basically, I have no philosophical 
>> problem with changing Folder, but it is a core enough thing that we 
>> can't do it in a way that causes any b/w incompatibility.

I agree that if we change Folder backward-compat is paramount.

But FWIW, note that in Nuxeo CPS we've always been using a monkey patch 
that added ordering to Folder without any problem.
(http://cvs.nuxeo.org/cgi-bin/viewcvs.cgi/OrderedFolderSupportPatch/)

> And now some comments:
> 
>> - in a folder, has_order_support would be either a boolean, or not 
>> present and thus found by acquisition
>> - the zope root would have has_order_support = 0
> 
> I'm not sure if acquisition is useful in this case: Move a Folder out of 
> that subtree and you lose OrderSupport. That's confusing.

You can always add it back. Also, in the use cases I envision it's not 
very common to do that, there is usually one or two roots of ordered 
folders that contain content objects and that's it. A CMF portal can 
easily be ordered everywhere without problem.

> Explicit is better than implicit ;)

I could do without it, it would just mean that in my CMS (Nuxeo CPS) any 
kind of folder creation (for any subclass) would have to explicitely set 
that attribute.


>> - OrderSupport.manage_renameObject would do its special stuff only if 
>> self.has_order_support is true
> 
> 
> Is there really a need to provide b/w compatibility for this behaviour? 
> The only use case I know is 'ordering-by-heavy-renaming', and people 
> using that should better migrate to the OrderSupport API.

Well it doesn't hurt, and keeps the original speed if folder is not ordered.

>> - dtml/main.dtml would test ordering with a simple
>>   <dtml-let hasOrderSupport=has_order_support>
>> - dtml/folderAdd.dtml would present the user with a choice to 
>> basically decide if has_order_support should be set, unset or acquired.
>> - manage_addFolder would take this additional argument and do nothing 
>> or create a property for has_order_support.
>>
>> Thus the default behavior would be the same as today, but if a folder 
>> is created with the has_order_support property (or if it's set after 
>> creation), the subtree would then be ordered. In a CMS that's always 
>> what we want.
> 
> 
> Would there be any UI to change that property? How would you set it 
> after creation?

Just the Properties tab. You'd have to know the name of the property to 
add. Or we could add an Ordering tab.

>> The only downside is, I think that products like BTreeFolder2 would 
>> have to add an has_order_support=0 class variable.
> 
> 
> Should be easy to detect BTreeFolders.

Yes, in manage_renameObject we could to that.


Florent



-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 87  http://nuxeo.com  mailto:fg@nuxeo.com