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.
Martin -- (muted) _______________________________________________ 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