Martin Aspeli wrote:
> Hanno Schlichting wrote:
>> Yep, you are wrong ;)
> Fair enough. Out of curiosity, does the object have a __parent__?

Nope, not ILocation aware :(

> In any case, I think your original suggestion is a good one. Let's take
> this opportunity to diagnose the problem and not the symptom: "True"
> tools should be singletons and act much like utilities. Stuff like
> self.REQUEST is pretty nasty. Maybe some tools will need some internal
> cleanup in that respect; my feeling is that in most cases, that cleanup
> should be reasonably easy, and where it's not perhaps we wait to put
> those methods into the corresponding utility interfaces and think about
> using adapters instead.

The only question is who does this tool cleanup ;)

> As Tres points out, you need aq context for security and in case
> something is contained in the tool and needs proper containment
> acquisition. portal_factory is such an example. I don't know if
> portal_actions would be now as well; portal_types probably too.
> These are not really utilities, though, they are magic singleton
> containers for specific things. Whereas a tool that is converted to a
> utility may one day be deprecated out of content space, these ones may
> not, I don't know.

Hhm, ok. So do we expose these tools at utilities now at all? Can we
really deprecate getToolByName then?

> Also, getToolByName remains and is almost certainly the way forward for
> all TTW code still, because it lets us aq wrap, it removes the need to
> make all interfaces importable in untrusted code, and it can do any
> additional security related things. In filesystem code, though, I think
> the security aspect won't matter in most cases.

Jens came up with a nice alternative here, which is
getToolByInterfaceName. The docstrings reads:

"""Get a tool by its fully-qualified dotted interface path. This method
replaces getToolByName for use in untrusted code. Trusted code should
use zope.component.getUtility instead."""


Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to