Hanno Schlichting wrote:

Yep, you are wrong ;)

Fair enough. Out of curiosity, does the object have a __parent__?

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.

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.

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.


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

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

Reply via email to