Yesterday I tried to do my homework from the CMF-mini-sprint in Potsdam. I reread the tools-as-utilities discussion and had again a closer look at the code. In Potsdam we decided to wrap persistent utilities with a complete acquisition context. But now I think this would be a mistake, so instead if implementing this I wrote a new proposal.

A complete acquisition chain usually contains the REQUEST object. This makes it impossible to cache wrapped utilities across request boundaries and supports the usage of self.REQUEST - something that should not be available in utilities.

I believe using self.REQUEST in tools was never a good idea, tools that can't be fixed should not be registered as utilities. five.localsitemanager should remove the REQUEST object from the acquisition chain before re-wrapping tools. AFAICS this makes the wrapped tools no longer request specific, making it possible to cache them.


1.) ActionProviderBase depends on self.REQUEST and is not easy to fix. But most tools don't use ActionProviderBase anymore, so some tools like MetadataTool, PropertiesTool and SyndicationTool can be fixed by just removing that base class.

2.) Some tools make limited use of self.REQUEST, I propose to remove ActionProviderBase and to apply these additional fixes:

a) MemberDataTool: remove _v_temps cache for MemberData objects, store new MemberData objects always in self._members (AFAICS this cache is only useful if most users use the default member data, so storing MemberData objects persistently would be unnecessary.)

b) MembershipTool: add required REQUEST argument to credentialsChanged

c) RegistrationTool: add required REQUEST argument to registeredNotify

3.) Some tools like URLTool, TypesTool, ActionsTool and CookieCrumbler can't be fixed easily. Their registration as utilities should be removed for now. The methods that depend on self.REQUEST should be deprecated and replaced by views.

Does that make sense? If there are no objections I'll move on in that direction. This week I have some time to work on the implementation.



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

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

Reply via email to