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  -  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

Reply via email to