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

[Alec Mitchell]

On 4/3/07, yuppie <y.2007- at wcm-solutions.de> wrote:
> Hi!
>
>
> Alec Mitchell wrote:
> > On 4/1/07, yuppie <y.2007--E2EsyBC0hj3+aS/vkh9bjw at public.gmane.org> wrote:
> >> Philipp von Weitershausen wrote:
> >> > You're suggesting to introduce yet another package that's destined
> >> to go
> >> > a way at some point, while the same functionality is already available,
> >> > it only needs to be un-deprecated...
> >>
> >> I don't agree. CMF 2.0's getToolByName() requires context object and
> >> tool name as arguments, the tool has to be a content space object.
> >> That's quite different to five.lsm's getUtility():
> >
> > Well you already have a mapping of name to interface that you use for
> > BBB, and a context is required for acquisition wrapping, even it it's
> > done implicitly.  You can pass a context to a getUtility call too,
> > that doesn't make the utility live in content space.  In this case
> > using a secondary api for doing the wrapping makes it clear that we
> > aren't dealing with real utilities here but context-dependent tools,
> > which the CMF tools still are no matter how we look them up.
>
> AFAICS all CMF tool interfaces are valid utility interfaces. The fact
> they are currently implemented as content space tools is just an
> implementation detail. Using the utility I don't care how it is
> implemented. Why should I?
>
> All issues reported so far (KSS, GenericSetup) have nothing to do with
> getUtility not being explicit enough. AFAICS they have to do with the
> fact that some five.lsm methods return unwrapped tools. Something that
> has to be fixed.

I'm pretty sure this is incorrect.  My understanding is that KSS uses
a non-five.lsm site manager which is perfectly valid and works in both
Zope 2 and 3, but when it needs to delegate utility lookup to a site
manager earilier in the traversal chain which is a five.lsm, that
delegation breaks.  It would be possible to fix this in Zope 3 itself,
or as Hanno suggests by essentially monkey-patching Zope 3 so that it
was more accepting of unexpected behaviors from 3rd-party site-manager
implementations like five.lsm.  However, IMO, the better solution is
to make five.lsm play nicely with non-five.lsm site managers, which
means removing its acquisition magic.

...
> Using getUtility instead of getToolByName made life easier. You no
> longer have to care about which utility is implemented z2-style and
> which z3-style. And you can write less complex code if you don't have to
> pass in the context.

Right, it's easier because, IMO you are hiding the fact that the tools
you are using are context dependent and therefore not properly
implemented utilities.  Components which require a context to function
should be adapters, components which additionally require a request
should be views, those that require neither should be utilities.

...

Alec