[Zope-CMF] getToolByName depreciation, getUtility, and five.lsm

[Kapil Thangavelu]

A few of us (Alec Mitchell, Godefroid Chapelle, Balazs Ree, Rocky Burt,  
Daniel Nouri, Rob Miller, Vincenzo Di Somma, and myself) have been  
discussing this in depth at the Sorrento Sprint. We've reached consensus  
on how we hope to resolve the issues arising from the recent introduction  
of five.localsitemanager and the deprecation of getToolByName.

We believe that these recent changes have introduced implicit magic into a  
standard Zope3 api to fit Zope2 acquisition. There should be an explicit  
separate api if we want acquisition wrapped context-aware utilities. As an  
example of a symptom caused by the implicit implementation, KSS (which was  
developed as a pure zope 3 component) breaks when used with Plone, even  
though it is a perfectly valid z3 component. Once we return to using  
getToolByName for tool lookup, the KSS/Plone3 issue disappears, because  
the magic wrapping of things stops. This KSS/Plone3 issue arises because  
the five.lsm acquisition breaks down when you add in non five.lsm  
component registries. If you need Zope2 acquisition, you should use an  
accessor api to get things wrapped.

In addition, getToolByName is the most fundamental and widely used api in  
all of CMF, and we're going to be issuing hundreds of deprecating warnings  
for every single cmf application extant.

As a solution, we propose

* The five.localsitemanager code should *NOT* be dealing with acquisition,  
it should be restricted to setting up a bases chain for persistent  
components that does parent lookup.

* getToolByName deprecation should be reverted. Its internal mechanisms  
should be kept the same as in the current CMF 2.1 release, using  
getUtility, *AND* it should be the one doing acquisition wrapping.

So instead of doing implicit magic in the getUtility call stack, let's be  
explicit, while still allowing the flexibility that registered components  
provide. Which in turn results in an untouched zope3 getUtility execution  
path for looking up utilities.

getToolByName should return acquisition wrapped utilities via name  
mapping, and become un-deprecated.  Context for wrapping would be the  
context passed as an argument to getToolByName, as it always has been. It  
would issue deprecation warnings when it has to lookup a tool via aq_get  
instead of getUtility. The mechanism for registering tool names would  
raise an error when anyone tries to register a component which does not  
support Acquisition.

The getToolByInterfaceName method would no longer be necessary as  
getToolByName can be called from restricted code.  However if needed it  
could remain and use the result of getSite() as the context for wrapping  
the tool resulting from the utility lookup.

We don't mean to belittle the hard work that anyone has put into this so  
far, and we hope this is received in the spirit that it is intended.  We  
are willing to implement this if we can reach some consensus that this is  
the right thing to do.

-kapil