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