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.


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

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

Reply via email to