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.
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
