Jens Vagelpohl wrote:
getToolByName does explicitly wrap, even when using getUtility under the
covers where it can. I don't forsee any compatibility problems there.
Cool, thanks for clearing that up.
The portal as utility is a good idea, I like it. This could be used in
many places where a tool itself wants to acquire something, which is
usually something else at the portal root. I'm not sure about the user
folder implications that you mention. The security machinery may fail if
a user originates in a user folder above the portal, which cannot be
reached by acquisition anymore.
That would of course also be bad; people expect to be able to log in
with their root admin username.
My concern is just that we need a robust solution that doesn't put too
much onus on the end developer. If I have to do this it's pretty horrendous:
>>> mtool = getUtility(IMembershipTool)
>>> mtool = mtool.__of__(context)
>>> # now use mtool
especially since the errors I get will likely be confusing. I have
learned the hard way that having to understand how acquisition interacts
with your code fully can be painful, and that sometimes the Zope2/Zope3
divide still forces this on developers. In this case, we need to make it
as hard as possible to make mistakes, or the learning curve will just
shoot up again.
In fact, I'm not quite sure I understand the full extent of the problem
here, which is why I'm not being more pro-active in offering suggestions.
Now, I assume we still create the tool objects as
portal['portal_membership'] or whatever, i.e. they are still
SimpleItem's or whatever, so they still have acquisition mixed in.
Presumably, they should also have an aq_parent always, no?
Then, I assume that on portal setup, we do
component=portal.portal_membership) - that is, we are telling the
persistent local utility registry that we are using the same physical
object (in the ZODB), rather than giving it a factory from which to
create its own object.
This is what leads to believe there ought to be an aq_parent by
containment, but I guess I may be wrong?
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests