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

[yuppie]

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.

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

Are there other examples besides KSS? The solution Hanno proposed 
doesn't sound very painful.

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.


I didn't push for releasing a beta. But I consider a beta release a 
commitment that we make big changes on the CMF 2.1 branch only if really 
necessary.


Cheers,

	Yuppie