Re: [Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
On Tue, Jun 21, 2005 at 03:14:49PM +0200, Christian Heimes wrote: > yuppie wrote: > >That sounds *much* better :) > > > >But please use OrderSupport instead of OrderedFolder. That makes the > >inheritance tree much simpler and you don't have to override the methods > >again: > > > > class PortalFolder(OrderSupport, PortalFolderBase): > > I'm on it. The unit tests are running. Which unit tests? Is CMFBTreeFolder now supposed to be working against the new CMF 1.5.2beta ? It doesn't seem to be here, I still get the same AttributeError in manage_renameObject(). Or do I need to get a new version of BTreeFolder2 from somewhere? I have the 1.0.1 version from hathawaymix.org. -- Paul Winkler http://www.slinkp.com ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
Christian Heimes wrote at 2005-6-20 20:19 +0200: >Dieter Maurer wrote: >> The new behaviour was ill conceived (it missed the need >> for portal folders without order support as exemplified >> by "CMFBTreeFolder"). >> >> We now notice this bug. It should be fixed. >> >> I think, it would be acceptable as fix to introduce >> a new "PortalFolderBase" (or similarly named) class >> as *the* base class for all portal folders. > >You are a little late, Dieter. *g* I have already added PortalFolderBase >and fixed BTreeFolder2. I am reading the digest which I usually receive once a day (and read in the evening)... -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
Tres Seaver wrote: We should chat about that. I created a Zope collector issue for that, and started work on it yesterday, About CMFBTreeFolder? Yeah it should be moved into CMF in the long run. My fix is working and we have time to fix it w/o hurry. I think it must be that your e-mail address on your www.zope.org account isn't subscribed to the cmf-checkins list. What I do is subscribe it, and then immediately disable delivery, because I read the lists via gmane's NNTP gateway. That sounds resonable. I'm going to subscribe all import lists tonight. Christian ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Heimes wrote: > Tres Seaver wrote: > >> Thanks, Christian. I just forward-ported your change to the CMF-head. >> Please don't leave that out in the future! > > > You are too fast for me. *g* > I had to set up a sandbox for HEAD and I was fixing BTreeFolder2 in Zope > and cvs. We should chat about that. I created a Zope collector issue for that, and started work on it yesterday, > PS: My checkins don't appear in the checkin list. Could you have a look > at it please? I think it must be that your e-mail address on your www.zope.org account isn't subscribed to the cmf-checkins list. What I do is subscribe it, and then immediately disable delivery, because I read the lists via gmane's NNTP gateway. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCuBVp+gerLs4ltQ4RAp8OAJ9b9OrGifybrDY2gva0n/1s5720MwCaA6ty v8366SLkSwEWpvO8BPghqBw= =AwRQ -END PGP SIGNATURE- -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
yuppie wrote: That sounds *much* better :) But please use OrderSupport instead of OrderedFolder. That makes the inheritance tree much simpler and you don't have to override the methods again: class PortalFolder(OrderSupport, PortalFolderBase): I'm on it. The unit tests are running. Christian ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
Tres Seaver wrote: Thanks, Christian. I just forward-ported your change to the CMF-head. Please don't leave that out in the future! You are too fast for me. *g* I had to set up a sandbox for HEAD and I was fixing BTreeFolder2 in Zope and cvs. Christian PS: My checkins don't appear in the checkin list. Could you have a look at it please? ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Heimes wrote: > Dieter Maurer wrote: > >> The new behaviour was ill conceived (it missed the need >> for portal folders without order support as exemplified >> by "CMFBTreeFolder"). >> >> We now notice this bug. It should be fixed. >> >> I think, it would be acceptable as fix to introduce >> a new "PortalFolderBase" (or similarly named) class >> as *the* base class for all portal folders. > > > You are a little late, Dieter. *g* I have already added PortalFolderBase > and fixed BTreeFolder2. Thanks, Christian. I just forward-ported your change to the CMF-head. Please don't leave that out in the future! Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCtw2W+gerLs4ltQ4RApuQAJ9gV0CR9Yoa32XuA35GhRHbEgwTKACgvIcL 9ibYJkzfvuISjksOgjjLgeM= =RoMs -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
Hi Christian! Christian Heimes wrote: yuppie wrote: 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'm sorry but I'm a little bit nervous. I have to get Plone 2.1 up and running on CMF 1.5 until saturday or Plone 2.1 will stay on CMF 1.4. Accepted. I have another idea. The patch is attached to this mail. In short terms I have renamed PortalFolder to PortalFolderBase subclassed of Folder and created a new PortalFolder class subclassed from OrderedFolder. PortalFolderBase contains nearly all code from PortalFolder. This way it is easy to subclass from PortalFolderBase w/o ordered support. class PortalFolderBase(DynamicType, CMFCatalogAware, Folder): class PortalFolder(PortalFolderBase, OrderedFolder): manage_renameObject = OrderedFolder.manage_renameObject.im_func tpValues = OrderedFolder.tpValues.im_func That sounds *much* better :) But please use OrderSupport instead of OrderedFolder. That makes the inheritance tree much simpler and you don't have to override the methods again: class PortalFolder(OrderSupport, PortalFolderBase): Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
Dieter Maurer wrote: The new behaviour was ill conceived (it missed the need for portal folders without order support as exemplified by "CMFBTreeFolder"). We now notice this bug. It should be fixed. I think, it would be acceptable as fix to introduce a new "PortalFolderBase" (or similarly named) class as *the* base class for all portal folders. You are a little late, Dieter. *g* I have already added PortalFolderBase and fixed BTreeFolder2. Christian ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
Julien Anguenot wrote at 2005-6-20 11:19 +0200: >Christian Heimes wrote: > ... >> 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. > >- -1. You can change the code of your product to cope with it. (i.e : we >did this on CPS a long time ago) I, on the contrary, am in favour of such a change. "CMFBTreeFolder" demonstrates that there is a useful use case for a "PortalFolder" *without* order support. *AT LEAST*, there should be a "PortalFolder" base class without order support (which might have a different name). -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
yuppie wrote at 2005-6-20 11:56 +0200: > ... >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. Maybe, we should change this: "PortalFolder" is not part of "CMFDefault" but of "CMFCore". Its name suggests it as the base class for all portal folders. "CMFBTreeFolder" provides a convincing use case that some portal folders should *not* have order support. > ... >I'm open for any proposal that adds a *new* base class for CMF folders. If we do not want to use "PortalFolder" as the base class for all portal folders (which I would prefer), we might introduce a new "PortalFolderBase" for precisely this purpose. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
Jens Vagelpohl wrote at 2005-6-20 11:48 +0100: > ... >I support that statement. In my opinion it is unacceptable to make >this change on the CMF 1.5 branch at this point. If there is a >problem, please change the software that relies on the old behavior >instead. The new behaviour was ill conceived (it missed the need for portal folders without order support as exemplified by "CMFBTreeFolder"). We now notice this bug. It should be fixed. I think, it would be acceptable as fix to introduce a new "PortalFolderBase" (or similarly named) class as *the* base class for all portal folders. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
On 20 Jun 2005, at 18:22, Tres Seaver wrote: Yvo, Jens, Florent: you were the last ones to chime on on the "CMF 1.5.2" thread; would that work for you, assuming we merge Christian's patch? I can tag at any point in time. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
Tres Seaver <[EMAIL PROTECTED]> wrote: > > I have another idea. The patch is attached to this mail. In short terms > > I have renamed PortalFolder to PortalFolderBase subclassed of Folder and > > created a new PortalFolder class subclassed from OrderedFolder. > > PortalFolderBase contains nearly all code from PortalFolder. This way it > > is easy to subclass from PortalFolderBase w/o ordered support. > > > > class PortalFolderBase(DynamicType, CMFCatalogAware, Folder): > > > > class PortalFolder(PortalFolderBase, OrderedFolder): > > manage_renameObject = OrderedFolder.manage_renameObject.im_func > > tpValues = OrderedFolder.tpValues.im_func > > > > All tests are running fine. > > I'm +1 for this, but you can't expect us to release a new CMF 1.5 > release by Saturday. If you are OK releasing a Plone 2.1 beta atop CMF > 1.5.2b1, then we could probably agree to tag that beta by then. > > Yvo, Jens, Florent: you were the last ones to chime on on the "CMF > 1.5.2" thread; would that work for you, assuming we merge Christian's > patch? I'm ok with it. Of course there's no problem in making a non-release related tag if it helps checkpointing stuff. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
Tres Seaver wrote: I'm +1 for this, but you can't expect us to release a new CMF 1.5 release by Saturday. If you are OK releasing a Plone 2.1 beta atop CMF 1.5.2b1, then we could probably agree to tag that beta by then. There is no need for a release. All I need is a running version of CMF 1.5 to proof that it is working. It would be nice if I would be allowed to create a tag for us. We are going to migrate plone.org to Plone 2.1 at EuroPython. If plone.org runs on CMF 1.5 we will use CMF 1.5 for Plone 2.1. Christian ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Heimes wrote: > yuppie wrote: > >> 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. > > > Oh you are right. I had in mind that all content types are declared in > CMFDefault. In this case I have to retract my proposal. > >> 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'm sorry but I'm a little bit nervous. I have to get Plone 2.1 up and > running on CMF 1.5 until saturday or Plone 2.1 will stay on CMF 1.4. > >> 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. > > > I have another idea. The patch is attached to this mail. In short terms > I have renamed PortalFolder to PortalFolderBase subclassed of Folder and > created a new PortalFolder class subclassed from OrderedFolder. > PortalFolderBase contains nearly all code from PortalFolder. This way it > is easy to subclass from PortalFolderBase w/o ordered support. > > class PortalFolderBase(DynamicType, CMFCatalogAware, Folder): > > class PortalFolder(PortalFolderBase, OrderedFolder): > manage_renameObject = OrderedFolder.manage_renameObject.im_func > tpValues = OrderedFolder.tpValues.im_func > > > All tests are running fine. I'm +1 for this, but you can't expect us to release a new CMF 1.5 release by Saturday. If you are OK releasing a Plone 2.1 beta atop CMF 1.5.2b1, then we could probably agree to tag that beta by then. Yvo, Jens, Florent: you were the last ones to chime on on the "CMF 1.5.2" thread; would that work for you, assuming we merge Christian's patch? Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCtvts+gerLs4ltQ4RAjjQAKCWaIXrIJlsWi2hpq6FAWvVQmC3zgCferj3 lePS2AT22F0+dRA81fwI4z0= =iNyd -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
yuppie wrote: 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. Oh you are right. I had in mind that all content types are declared in CMFDefault. In this case I have to retract my proposal. 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'm sorry but I'm a little bit nervous. I have to get Plone 2.1 up and running on CMF 1.5 until saturday or Plone 2.1 will stay on CMF 1.4. 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. I have another idea. The patch is attached to this mail. In short terms I have renamed PortalFolder to PortalFolderBase subclassed of Folder and created a new PortalFolder class subclassed from OrderedFolder. PortalFolderBase contains nearly all code from PortalFolder. This way it is easy to subclass from PortalFolderBase w/o ordered support. class PortalFolderBase(DynamicType, CMFCatalogAware, Folder): class PortalFolder(PortalFolderBase, OrderedFolder): manage_renameObject = OrderedFolder.manage_renameObject.im_func tpValues = OrderedFolder.tpValues.im_func All tests are running fine. Christian Index: CMFCore/PortalFolder.py === RCS file: /cvs-repository/Products/CMFCore/PortalFolder.py,v retrieving revision 1.71.2.8 diff -u -r1.71.2.8 PortalFolder.py --- CMFCore/PortalFolder.py 14 Jun 2005 16:39:33 - 1.71.2.8 +++ CMFCore/PortalFolder.py 20 Jun 2005 17:10:54 - @@ -26,6 +26,7 @@ from Globals import DTMLFile from Globals import InitializeClass from OFS.OrderedFolder import OrderedFolder +from OFS.Folder import Folder from CMFCatalogAware import CMFCatalogAware from DynamicType import DynamicType @@ -96,22 +97,19 @@ ) -class PortalFolder(DynamicType, CMFCatalogAware, OrderedFolder): +class PortalFolderBase(DynamicType, CMFCatalogAware, Folder): +"""Base class for portal folder """ -Implements portal content management, but not UI details. -""" -meta_type = 'Portal Folder' -portal_type = 'Folder' +meta_type = 'Portal Folder Base' -__implements__ = (IFolderish, DynamicType.__implements__, - OrderedFolder.__implements__) +__implements__ = (IFolderish, DynamicType.__implements__, Folder.__implements__) security = ClassSecurityInfo() description = '' - -manage_options = ( OrderedFolder.manage_options + - CMFCatalogAware.manage_options ) + +manage_options = ( Folder.manage_options + + CMFCatalogAware.manage_options ) def __init__( self, id, title='' ): self.id = id @@ -165,15 +163,6 @@ typ.isConstructionAllowed( container ) , result ) -security.declareProtected(AddPortalFolders, 'manage_addPortalFolder') -def manage_addPortalFolder(self, id, title='', REQUEST=None): -"""Add a new PortalFolder object with id *id*. -""" -ob = PortalFolder(id, title) -self._setObject(id, ob) -if REQUEST is not None: -return self.folder_contents( # XXX: ick! -self, REQUEST, portal_status_message="Folder added") def _morphSpec(self, spec): ''' @@ -433,7 +422,7 @@ self.manage_addFolder( id=id, title='' ) def _checkId(self, id, allow_dup=0): -PortalFolder.inheritedAttribute('_checkId')(self, id, allow_dup) +PortalFolderBase.inheritedAttribute('_checkId')(self, id, allow_dup) if allow_dup: return @@ -533,7 +522,7 @@ # Call OFS' _verifyObjectPaste if necessary if not securityChecksDone: -PortalFolder.inheritedAttribute( +PortalFolderBase.inheritedAttribute( '_verifyObjectPaste')(self, object, validate_src) # Finally, check allowed content types @@ -551,7 +540,6 @@ % type_name) security.setPermissionDefault(AddPortalContent, ('Owner','Manager')) -security.setPermissionDefault(AddPortalFolders, ('Owner','Manager')) security.declareProtected(AddPortalFolders, 'manage_addFolder') def manage_addFolder( self @@ -581,6 +569,37 @@ if REQUEST is not None: return self.manage_main(self, REQUEST, update_menu=1) + +InitializeClass(PortalFolderBase) + + +class PortalFolder(PortalFolderBase, OrderedFolder): +""" +Implements portal content management, but not UI details. +""" +meta_type
Re: [Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
Tres Seaver <[EMAIL PROTECTED]> wrote: > Christian Heimes wrote: > > Jens Vagelpohl wrote: > > > >> On a general note, if this is so important I am puzzled that this is > >> coming up now and not *months* ago. CMF 1.5.0 has been released ages > >> ago. Beta testing periods are the time to find and solve these > >> problems, not the middle of the maintenance release cycle... > > > > I'm puzzled, too. It looks like nobody has ever used or tested > > CMFBTreeFolder under CMF 1.5. I suspect the reason is that most people don't use CMFBTreeFolder directly but just mixin BTreeFolder2 with whatever classes they need. At least that's what we do. > Agreed. I'll bet that there is a trivial fix which would resolve the > issue. I *really* don't like the fact that the CMF-dependent parts got > merged into the core Zope product in 2.8; we should remove that, and > perhaps land the "fixed" CMFBTree module in CMFCore. I also support moving CMFBTreeFolder out of the Zope 2.8 core, if we can find a way of doing it with minimal impact (and taking into account that a little impact now is better than a big headache in the future when things diverge). The inclusion of BTreeFolder was good, but nobody thought of the CMFBTreeFolder in it. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Heimes wrote: > Jens Vagelpohl wrote: > >> On a general note, if this is so important I am puzzled that this is >> coming up now and not *months* ago. CMF 1.5.0 has been released ages >> ago. Beta testing periods are the time to find and solve these >> problems, not the middle of the maintenance release cycle... > > I'm puzzled, too. It looks like nobody has ever used or tested > CMFBTreeFolder under CMF 1.5. Agreed. I'll bet that there is a trivial fix which would resolve the issue. I *really* don't like the fact that the CMF-dependent parts got merged into the core Zope product in 2.8; we should remove that, and perhaps land the "fixed" CMFBTree module in CMFCore. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCtroa+gerLs4ltQ4RAr7wAKCmLttLEY8ToRZZLnnpjSHaP5LePwCfbqRa XF29ok/wBzApV8dy+srCuVM= =P1Fz -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
On 20 Jun 2005, at 10:56, yuppie wrote: 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 support that statement. In my opinion it is unacceptable to make this change on the CMF 1.5 branch at this point. If there is a problem, please change the software that relies on the old behavior instead. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
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 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
Jens Vagelpohl wrote: On a general note, if this is so important I am puzzled that this is coming up now and not *months* ago. CMF 1.5.0 has been released ages ago. Beta testing periods are the time to find and solve these problems, not the middle of the maintenance release cycle... I'm puzzled, too. It looks like nobody has ever used or tested CMFBTreeFolder under CMF 1.5. Christian ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. > +1 > 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. - -1. You can change the code of your product to cope with it. (i.e : we did this on CPS a long time ago) > >> 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. For this, my point is that you can change your code. (it could have been done long time ago) [...] > > >> 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. +1 J. - -- Julien Anguenot | Nuxeo R&D (Paris, France) CPS Platform : http://www.cps-project.org Zope3 / ECM : http://www.z3lab.org mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCtooEGhoG8MxZ/pIRAtXZAJ9/xHgACbMMjusJbnyhwYR7W4RndgCcCEU2 cwhGzd7a3gbKsBu5vPWZrwk= =QZcu -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
On 20 Jun 2005, at 09:24, 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. 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. On a general note, if this is so important I am puzzled that this is coming up now and not *months* ago. CMF 1.5.0 has been released ages ago. Beta testing periods are the time to find and solve these problems, not the middle of the maintenance release cycle... jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
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 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder
Hi Christian! Christian Heimes wrote: CMF 1.5's implementation of PortalFolder conflicts with CMFBTreeFolder. CMF 1.4: class PortalFolder(DynamicType, CMFCatalogAware, Folder) CMF 1.5: class PortalFolder(DynamicType, CMFCatalogAware, OrderedFolder) BTreeFolder2: class CMFBTreeFolder(BTreeFolder2Base, PortalFolder) traceback: File "/opt/zope/instances/plone21z28cmf15/Products/ATContentTypes/content/base.py", line 312, in processForm self.setId(new_id) File "/opt/zope/instances/plone21/Products/Archetypes/BaseObject.py", line 231, in setId parent.manage_renameObject( File "/opt/zope/releases/Zope-2_8-branch/lib/python/OFS/OrderSupport.py", line 255, in manage_renameObject old_position = self.getObjectPosition(id) File "/opt/zope/releases/Zope-2_8-branch/lib/python/OFS/OrderSupport.py", line 222, in getObjectPosition return ids.index(id) AttributeError: 'OOBTreeItems' object has no attribute 'index' As you can see CMFBTreeFolder doesn't work any more because PortalFolder is now subclassed from OrderedFolder. The changes to PortalFolder are *not* backward compatible. IMO they should be reverted and an OrderedPortalFolder class should be created for people how like to have ordered folders in CMF. 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. I propose to override manage_renameObject in PortalFolder with code that works for OrderedFolder *and* CMFBTreeFolder. Cheers, Yuppie 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. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests