[Zope-CMF] Re: [dev] unresolved site manager related issues

[Wichert Akkerman]

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 <y.2007- at wcm-solutions.de>  
> >> 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 <wichert at wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.