[Zope-CMF] Re: [dev] five.localsitemanager: proposal

[Martin Aspeli]

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