Hi Rob!

Rob Miller wrote:
currently, in the TypesTool.manage_addTypeInformation method in CMF 1.6, if a typeinfo_name argument is passed in and the corresponding fti is not found in the results of listDefaultTypeInformation, an error is raised. in CMF 2.0, this argument is ignored completely.

in 1.6, some types will be listed in the listDefaultTypeInformation while others will not, depending on whether those types were defined using a GenericSetup profile or if it was done old-style.

would anyone foresee a problem w/ changing the behaviour of this such that an error isn't raised when the typeinfo_name isn't found?

I don't remember why I made CMF 2.0 just ignore that argument. I think manage_addTypeInformation should at least issue a warning if that argument is not None.

Maybe it would even be better to remove that argument completely in CMF 2.0. I doubt there exists a lot of code that passes in the default None as typeinfo_name argument. And all other usages of the typeinfo_name argument are anyway broken.

CMF 2.0 doesn't provide a smooth migration path from fti based configuration to GenericSetup based configuration because it is hard to support both. I'll leave it up to you to find the right compromises for CMF 1.6, but I would propose to issue at least a warning if typeinfo_name isn't found.



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

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

Reply via email to