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.
Cheers,
Yuppie
_______________________________________________
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
