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

[Alec Mitchell]

On 4/1/07, yuppie <y.2007- at wcm-solutions.de> wrote:
> Hi!
>
>
> Philipp von Weitershausen wrote:
> > Hanno Schlichting wrote:
> >> 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.
> >
> > But Products.Five.BrowserView hides that particular detail from you, as
> > much as getToolByName could hide the acquisition detail when looking up
> > tools.
> >
> > 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.

> - You can easily replace z2-style tools by z3-style utilities.
> getUtility doesn't care about the implementation, just about the interface.

We're talking about making getToolByName use getUtility but perform
acquisition wrapping using the passed in context so that the tools
work and can still be used from restricted code.  This benefit is not
lost.

> - You don't have to provide a context object. This makes it easier to
> write new z3-style code.

You still need one, you just get it via implicit magic.  The tools all
require it still, once they don't there will be no problem with using
getUtility for them.  It's now possible to write real
context-independent z3 code (which is what the KSS stuff was doing
when lsm broke it), this implicit context just makes doing so more
painful, IMO.

...

Alec