[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
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
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
[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
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
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 RD (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
[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
[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
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
-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 Designhttp://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
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 RD +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
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 = 'Portal Folder'
+
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 RD +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
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
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
[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
