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

[yuppie]

Hi!


Alec Mitchell wrote:
> On 4/3/07, yuppie <y.2007--E2EsyBC0hj3+aS/vkh9bjw at public.gmane.org> wrote:
>> 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.

I did not debug this, I just did have a quick look at the code. I would 
be surprised if the KSS site manager removes acquisition wrappers, so 
the problem is that KSS gets the tools unwrapped. The tools are 
registered in the five.lsm, therefore five.lsm should be responsible for 
wrapping them.

But the way lookups are delegated to other site managers seems to be 
highly optimized and making use of internal apis of five.lsm. So it 
might not be possible to fix this in five.lsm, in which case Hanno's 
proposal would provide a solution.

Of course I might be wrong. A detailed bug report would make it easier 
to identify the exact problem.

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

The term 'context' is used in many different ways. The context required 
by getToolByName is different from the context required by adapters. It 
is just used to get the site root by acquisition. Zope 3 utilities also 
behave different depending on their site 'context'.

> components which additionally require a request
> should be views, those that require neither should be utilities.

Usually REQUEST is an argument of tool methods and not looked up by 
acquisition.


Cheers,

	Yuppie