Previously Tres Seaver wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Martin Aspeli wrote: > > Kapil Thangavelu wrote: > >> On Thu, 12 Apr 2007 06:16:23 -0400, yuppie <[EMAIL PROTECTED]> > >> wrote: > >> > >>> Hi! > >>> > >>> > >>> Philipp von Weitershausen wrote: > >>>> yuppie wrote: > >>>> Kapil's also right when he says that utilities by principle are > >>>> context-less components. > >>> By principle all Zope 3 code might depend on setSite to work as > >>> expected. We just don't pass that 'site context' explicitly to the > >>> component as in Zope 2. > >>> > >> contextual lookup is very a different notion, that context implementation > >> dependence. utilities don't have context implementation dependencies in > >> zope3, the majority of cmf tools do. > > > > Just so we are clear, can anyone point to a good example of a > > not-trivial-to-change place where CMF tools have inherent dependencies > > on acquisition? > > Security is inherently "placeful" in Zope2: it requires being able to > verify that the logged-in user is authenticated in a user folder which > is in the "scope" of the protected resource. > > As far as I'm concerned, Zope3's model is *not* intrinsically superior: > it doesn't support the use cases of the Zope2 model at all. Let's just > forget the "Zoep3 is better" mantra and find a workable near-term > solution here: if we have to re-implement / tweak some Zope3 machinery > to make it "play nice" in Zope2, then let us do so, rather than > distorting both in a misguided effort at "Zope3 purity." > > - If that means continuing to use 'getToolByName' for traditional tools > which need Zope2 security, fine; folks who implement new utilities > which don't need that compatibility can register them as pure > utilities. > > - If it's easier to hack the LSM stuff to automagically wrap those > returned utilities which implement IAcquisitionWhatever, fine; if > that means in turn that folks must use the Zope2 LSM version in > subsites, fine.
My current preference would be to keep using getToolByName while we rewrite the tools to work as utilities. Once a tool works as a utility which does not need to be acquisition-wrapper we can deprecate use of getToolByName for just that utility. I have a suspicion that this will be easy for most utilities. We can put that framework in place for CMF 2.1 and start refactoring the tools into utilities on CMF trunk. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. _______________________________________________ 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