[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode

[Martin Aspeli]

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 
registerUtility(provides=IMembershipTool, 
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?

Martin