Hi!
Alec Mitchell wrote:
On 4/3/07, yuppie <y.2007--E2EsyBC0hj3+aS/[EMAIL PROTECTED]> 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
_______________________________________________
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
