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
- 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
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