[Zope-CMF] CMF 1.6 change broke Plone compatibility

2005-12-20 Thread Jens Vagelpohl

Yvo,

The following checkin on the 1.6 branch, which looks like a pure  
cleanup item, completely breaks Plone 2.1 and up on CMF 1.6. I assume  
that was not the intention.


http://svn.zope.org/CMF/branches/1.6/CMFCore/TypesTool.py? 
rev=40364r1=40360r2=40364


I'm in the specific situation where I have an existing Plohn 2.1 site  
and I want to use PAS. The latest PAS depends in a current  
GenericSetup, so I am trying to move the Plone site onto the current  
CMF 1.6 branch. Due to the change above this is not possible.


Question: If we claim CMF 1.5 compatibility, do you mind reverting  
this checkin?


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] CMF 1.6

2005-11-18 Thread Chris Withers

Alec Mitchell wrote:
to start using it immediately or risk strange breakages.  Maintaining 
product compatibility between versions of CMF/Plone will become nearly 
impossible. 


I'm sorry, I really couldn't resist this...

And that differs from other Plone releases how exactly? ;-)

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
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] CMF 1.6

2005-11-16 Thread Florent Guillaume
I'd like to have some clarifications from the Plone team about what  
they expect to do w.r.t. events in CMF 1.6.


I see two possibilities:
1. you guys are prepared to do the work needed for Plone products to  
use super() in manage_afterAdd  co, in which case I can merge my  
branch into CMF 1.6
2. you feel that's too dangerous and, as Plone intends to use CMF  
1.6, I'll merge for CMF 2.0 only.


Be aware that if 2. is chosen, you won't be able to use Zope 3 events  
at all with CMF 1.6.


Florent

--
Florent Guillaume, Nuxeo (Paris, France)   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] CMF 1.6

2005-11-16 Thread Alec Mitchell
On Wednesday 16 November 2005 01:41 pm, Florent Guillaume wrote:
 I'd like to have some clarifications from the Plone team about what
 they expect to do w.r.t. events in CMF 1.6.

 I see two possibilities:
 1. you guys are prepared to do the work needed for Plone products to
 use super() in manage_afterAdd  co, in which case I can merge my
 branch into CMF 1.6
 2. you feel that's too dangerous and, as Plone intends to use CMF
 1.6, I'll merge for CMF 2.0 only.

 Be aware that if 2. is chosen, you won't be able to use Zope 3 events
 at all with CMF 1.6.

I'm a bit worried about the potential consequences here, so I'd say #2 is 
probably a necessity.  Even then, using super in a such a ubiquitously 
inherited class seems very dangerous.  Though I'm by no means an expert on 
the pitfalls of super(), my worry is that there are many products out there 
that subclass CMFCatalogAware, either directly or through 
BaseObject-CatalogMultiplex-CMFCatalogAware.  Even if we move to using 
super in BaseObject and CatalogMultiplex, we still have the problem of 
subclasses of BaseObject (i.e. nearly everything in the plone universe these 
days) needing to use super in any manage_after/before* methods (overriding 
e.g. manage_beforeDelete and delegating back to the parent class is quite 
common).

Am I misunderstanding here, or is this change going to break any 3rd party 
product that uses CMFCatalogAware and overrides manage_before* without using 
super()?  The fix for these products would be for them to also use super and 
possibly reorder their baseclasses so that the super users come first 
(though according to http://fuhm.org/super-harmful/, that still may result 
in unexpected behavior).  This would seem unacceptable for the next point 
release of Plone.  If this is going into CMF 2.0, then it's yet another 
reason for plone to stay clear of CMF 2.0 for a little while.

The big problem with this move is there's no way to give product developers 
warning.  They can't start using super now, because none of the base classes 
use it, but once super is in place in the base classes developers will need 
to start using it immediately or risk strange breakages.  Maintaining 
product compatibility between versions of CMF/Plone will become nearly 
impossible.  Doesn't look like there are any alternatives for getting 
add/delete/copy events working under zope2 though.

Alec
___
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] CMF-1.6 branch created (was Re: backporting GenericSetup to CMF-1.5)

2005-11-14 Thread Rob Miller

yuppie wrote:
I would not like to do this work on different branches, but if 
GenericSetup is a SVN external or if someone else does the merging I'm 
fine with creating the 1.6 branch earlier. Anyway I don't think 1.6 can 
be released before 2.0.


okay, i've created a CMF-1.6 branch that has branched everything from 
CMF-1.5 with the exception of CMFSetup and GenericSetup, which are 
svn:externals from the CMF trunk.


note that i've haven't actually started any backporting yet, and as such 
this branch is completely non-functional.  i hope to actually start work 
on it tomorrow evening (california time).


-r

___
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