Hi Yuppie,
This proposal is now implemented on CMF and five.localsitemanager trunk.
Everything *seems* to work, but maybe I'm missing something. This might
be a good time to review and test the changes - any feedback is welcome.
Well done - great work! :)
Done:
-----
There are 10 tools in CMF that are not ready for being used as
utilities, they have to be used the old way until they are fixed:
content_type_registry
cookie_authentication
portal_actions
portal_calendar
portal_catalog
portal_skins
portal_types
portal_uidhandler
portal_url
portal_workflow
Are these registered as utilities as all? Or only available using
getToolByName?
These 15 CMF tools are registered as utilities, AFAICS only the security
machinery uses their acquisition context (except for portal_membership,
which uses 'self.acl_users'):
Products.CMFActionIcons.interfaces.IActionIconsTool
Products.CMFCore.interfaces.ICachingPolicyManager
Products.CMFCore.interfaces.IDiscussionTool
Products.CMFCore.interfaces.IMemberDataTool
Products.CMFCore.interfaces.IMembershipTool
Products.CMFCore.interfaces.IMetadataTool
Products.CMFCore.interfaces.IPropertiesTool
Products.CMFCore.interfaces.IRegistrationTool
Products.CMFCore.interfaces.ISiteRoot
Products.CMFCore.interfaces.ISyndicationTool
Products.CMFCore.interfaces.IUndoTool
Products.CMFUid.interfaces.IUniqueIdAnnotationManagement
Products.CMFUid.interfaces.IUniqueIdGenerator
Products.GenericSetup.interfaces.ISetupTool
Products.MailHost.interfaces.IMailHost
five.localsitemanager now returns wrapped utilities without
RequestContainers. This requires a new LookupClass.
Interesting.
Do we still get deprecation warnings if these are looked up using
getToolByName?
My feeling is that we should *not* get deprecating warnings for these.
It's rather late in the day for this release to officially deprecate
such fundamental parts of CMF, and I fear that people won't be able to
remember which tools are now utilities and which ones are tools, since
the distinction really comes down to implementation detail.
Hopefully, the path forward is that *all* the tools become utilities
(your last to-do below). In that case, I think full deprecation of
lookup via getToolByName makes sense, since we have a uniform API
(getUtility()) for looking up CMF's fundamental components. Until then,
I think we should give people the choice on the utilities we still have,
but not prod them too hard.
ToDo:
-----
- real world testing
- backport to the CMF 2.1 branch
Is this in the pipeline? i.e. will this code land in Plone 3.0? :-)
- write migration code for CMF 2.1 beta sites that replaces the
LookupClass and removes some utility registrations
Plone will likely need the same migrations.
- fix the GenericSetup handler
How so?
- figure out if we can make acl_users an utility
Spooky...
- in the long run, modify all tools to make them work as utilities
Yes - as per above, I think this needs to be the ultimate goal.
AFAICS, KSS will no longer need the monkey patch if it sets the
LookupClass to FiveVerifyingAdapterLookup.
Great - this is really wonderful news.
Martin
--
Acquisition is a jealous mistress
_______________________________________________
Zope-CMF maillist - [email protected]
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
