Hi Rob! Hi Jens!

Rob Miller wrote:
Jens Vagelpohl wrote:

On 20 Dec 2005, at 19:53, yuppie wrote:

The intention was to make things consistent. CMF 1.5 and CMF 2.0 have different ways to register custom type info classes. Before that change both machineries were broken on the 1.6 branch because they were merged in an insane way.

I fixed the new machinery because

- most code used already the new machinery (and I thought that was Rob's intention)

- this doesn't break many products

I don't mind if you switch the 1.6 branch back to the old machinery, but there are more changes necessary than just reverting the last checkin.

Like what exactly?

With all due respect, the 1.6 branch should *not* break stuff that works find on 1.5. The specific goal for 1.6 was to be "1.5 plus GenericSetup" so that it stays 1.5-compatible. This change has nothing to do with GenericSetup from all I can tell. Please don't just say "OK, change it back if you want, but there may be traps elsewhere". I do not know what all needs to be changed. I'll be happy to do it, but I need to know what else is involved.

Besides the import/export handlers Rob mentions below this affects all the TypesTool code that used 'typeClasses' (grep for it in 1.5) and the add forms for type infos.

yes, i believe the agreement was to try to keep 1.6 as close to 1.5 as possible, with the exception of GenericSetup. the types stuff is the greyest area, however, because the changes in the way TypeInfo objects are handled btn 1.5 and 2.0 has a considerable impact on the setup profiles and the import/export nodes. my original idea was to have the 1.6 types import adapter use the 2.0 style, containment-based profile format, but to generate 1.5 style TypeInfo objects. i haven't had time in recent weeks to keep up w/ all of the stuff that you've been doing, yuppie, but i do have a bit of concern that we're causing too much divergence btn 1.5 and 1.6 operationally. if we stray too far, then tres will stop forward-porting any 1.5 fixes that he might make... ;-).

I really don't care much about how this is resolved. But from Rob's checkins and the discussion following this mail


I had the impression that CMF 1.6 should provide backwards compatibility for Products written for Plone 2.1, not for Plone 2.1 itself. CMFDynamicViewFTI is an integral part of Plone 2.2 and I would be surprised if any other Plone product registers its own type info class. AFAICS the same applies to FlexibleTypeInformation and CPS.

I don't think that my backports from the trunk widened that gap between 1.5 and 1.6. It existed from the beginning of the 1.6 branch.



Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to