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

2005-06-29 Thread Paul Winkler
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

2005-06-21 Thread Dieter Maurer
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

2005-06-21 Thread Christian Heimes

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

2005-06-21 Thread Tres Seaver
-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

2005-06-21 Thread Christian Heimes

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

2005-06-21 Thread Christian Heimes

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

2005-06-20 Thread Tres Seaver
-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

2005-06-20 Thread yuppie

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

2005-06-20 Thread Christian Heimes

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

2005-06-20 Thread Dieter Maurer
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

2005-06-20 Thread Dieter Maurer
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

2005-06-20 Thread Dieter Maurer
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

2005-06-20 Thread Jens Vagelpohl


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

2005-06-20 Thread Florent Guillaume
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

2005-06-20 Thread Christian Heimes

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

2005-06-20 Thread Tres Seaver
-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

2005-06-20 Thread Christian Heimes

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

2005-06-20 Thread Florent Guillaume
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

2005-06-20 Thread Tres Seaver
-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

2005-06-20 Thread Jens Vagelpohl


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

2005-06-20 Thread 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

___
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

2005-06-20 Thread Christian Heimes

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

2005-06-20 Thread Julien Anguenot
-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

2005-06-20 Thread Jens Vagelpohl


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

2005-06-20 Thread Christian Heimes

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

2005-06-20 Thread yuppie

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