Unless someone fixes that CMFDynamicsomethingFTI thing (or the CMF 1.6
branch) people cannot even attempt to run Plone 2.1 or 2.2 against CMF
1.6. This is like a stalemate. Can you suggest how to add a new kind of
factory information class similar to appending it to that typeClasses
structure so Martin can fix the Plone code for whatever release they
want to make CMF 1.6-compatible then?
We can obviously fix this, so long as we maintain API compatability. A lot
of products use CMFDynamicViewFTI, but only through the interfaces defined
there and in CMFPlone/interfaces/browserdefault.py.
*If* this is indeed a better solution, we'd need to know *how* to change
CMFDynamicViewFTI to use the new machinery. That code is fairly small and
simple, and someone who knows how an FTI works should hopefully not have
much problem understanding how it works. If you can outline how to fix it,
I'm sure we could get one applied and into a release timed to the switch
to CMF 1.6.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests