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:[EMAIL PROTECTED]


_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to