[Zope-CMF] [dev] five.localsitemanager: proposal

[yuppie]

Hi!


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.


Implementation:
---------------

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.


Cheers,

	Yuppie