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

[Hanno Schlichting]

Hi,

I'll just offer one alternative solution for disussion, which could
avoid reverting all the changes we made.

Kapil Thangavelu wrote:
> 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.

I would say that all of Acquisition is dark implicit magic and something
I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2
I also expect the need to make the Zope 3 code Acquisition aware. One
prime example are browser views, which I need to mix in Acquisition in
order for them to work. From my perspective the same could apply to site
managers / component registries. As we already need to make a
specialized subclass for local site managers to make them work in Zope 2
I think it would be another possibility to enforce the same for
non-persistent site managers.

This could lead us to a second package five.sitemanager that is aware of
the same kind of Acquistion wrapping that five.lsm implies right now.
The monkey patches we need right now could go away and KSS could do a
conditional import of the site manager from zope.component or
five.sitemanager if it is found.

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

Yes, and I think in order to move forward and someday be able to remove
tools from content space, not to mention not to enforce beginners to
learn about yet another CMF-ism named tools, we need to be prepared to
make some more intrusive changes sometimes.

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

In my alternative we would just need to add a little new package which
is mostly a copy/paste job, change KSS to do an conditional import (so
it still works in pure Zope 3) and document the change.

Looking at Zope 2.11 we will potentially get Acquisition through
__parent__ pointers which would allow us to make the implementation of
five.sitemanger a lot saner and ultimately allow us to remove it again
altogether.

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

All I'm interested in is a proper solution. Should that imply reverting
lots of things I have done it would be unfortunate but obviously the
right thing to do :)

Hanno