[Zope-dev] Re: Ordered Folder again
Hi! Florent Guillaume wrote: 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/) CPS doesn't subclass from PortalFolder? If CPS would have its own class like PloneFolder in Plone, you could just mix in OrderSupport. But maybe CMFCore.PortalFolder should mix in OrderSupport? Would that help to solve your problem? Cheers, Yuppie ___ 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 )
[Zope-dev] Re: Ordered Folder again
On Mon, 2003-06-23 at 17:17, Yuppie wrote: Florent Guillaume wrote: 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/) CPS doesn't subclass from PortalFolder? If CPS would have its own class like PloneFolder in Plone, you could just mix in OrderSupport. We could, except that - we want to be useable with standard CMF objects - everybody wants ordering But maybe CMFCore.PortalFolder should mix in OrderSupport? Would that help to solve your problem? That's definitely a thing that would be useful, but I still stand by my proposal. 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 )
[Zope-dev] Re: Ordered Folder again
Hi Florent! Florent Guillaume wrote: CPS doesn't subclass from PortalFolder? If CPS would have its own class like PloneFolder in Plone, you could just mix in OrderSupport. We could, except that - we want to be useable with standard CMF objects Was just asking. I think you're doing the Right Thing. - everybody wants ordering Well, you want ordering, I want ordering, many other people want it. But maybe it's a special content management need. But maybe CMFCore.PortalFolder should mix in OrderSupport? Would that help to solve your problem? That's definitely a thing that would be useful, but I still stand by my proposal. Wish you good luck! I'm not very happy with the changes you propose, but if it helps to convince people ... Cheers, Yuppie ___ 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 )
[Zope-dev] Re: Ordered Folder again
Hi Florent! 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. 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. Explicit is better than implicit ;) - 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. - 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? 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. Cheers, Yuppie ___ 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 )
[Zope-dev] Re: Ordered Folder again
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 )
