Alec Mitchell wrote:
On 4/1/07, yuppie <y.2007--E2EsyBC0hj3+aS/[EMAIL PROTECTED]> 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

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



Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to