Hi Jens,
getToolByName on the branch will give you a DeprecationWarning.
In light of what we're seeing here, and because there is *so* much third
party code using getToolByName(), perhaps a DeprecationWarning (and
worse, speedy deprecation) is a bit premature? I don't think we can get
rid of getToolByName() for a long time, practically, but new code should
be encouraged from using the new utility based lookup.
Before that happens, though, this needs to work 100% of the time,
without requring client code to play aq tricks.
The
branch does provide an alternative to getToolByName for untrusted
code that I think is close to the whole utility idea. I call it
"getToolByInterfaceName" and instead of a tool ID you pass in the
interface's dotted name as a string:
getToolByName(context, 'portal_actions')
would become
getToolByInterfaceName(context,
'Products.CMFCore.interfaces.IActionsTool')
whereas everything else stays the same, meaning you can pass in a
default, and the method will wrap the tool before handing it back.
However, instead of AttributeError, this one raises
ComponentLookupError, but that decision can always be revisited.
So what does this really buy us over, say, a map of tools names to
interfaces? Is it (in the short/medium term) really worth spewing
warning from tons and tons of code?
Now, the main issue is still there, how to deal with tool wrapping
when calling getUtility/queryUtility in trusted code. Doing it every
time right after the call is stupid. I like Tres' hardline assertion
that we must have it wrapped every time, automatically. This needs to
be implemented somehow, maybe in Five as he suggests.
I'm not quite sure I follow the argument that it must be wrapped every
time. I agree that it must for TTW code (page templates, scripts), for
security. For other things, we may want instead to rely on the pattern
that's been mentioned: use getUtility(ISiteRoot) to get the portal root
and don't rely on acquiring attributes (from self in the tool) otherwise.
I may not have fully understood the implications of this, though.
Martin
_______________________________________________
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
