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

[Wichert Akkerman]

Previously Tres Seaver wrote:
> Alec Mitchell wrote:
> > On 4/15/07, Martin Aspeli <optilude at gmx.net> wrote:
> >> Dieter Maurer wrote:
> >>> Alec Mitchell wrote at 2007-4-12 06:59 -0700:
> >>>> ...
> >>>> ... deprecation of "getToolByName" ...
> >>>> which is that there's no practical reason other than
> >>>> aesthetics to deprecate getToolByName at this point.
> >>> A very good point: let's deprecate deprecations done just for
> >>> aethetical reasons :-)
> >> Aesthetics were not the original reason for moving down this route, so
> >> it's a little unfair to cast it in that light. The main drivers, as I
> >> recall, were to encourage API usage that would allow us to move tools
> >> out of content space eventually, and to make code depending on CMF tools
> >> more consistent with "newer" code which may depend on new utilities (at
> >> least in the Plone world, there is a general consensus that we'd rather
> >> not have any more content-space tools from now on).
> > 
> > What is it about getToolByName that implies that tools are in content
> > space?  Consistency with "newer" code is an aesthetic concern as far
> > as I understand it.
> 
> Agreed.  I'm fine with having 'getToolByName' issue a deprecation
> warning if the tool can't be found using the component registry, and
> therefore the API has to fall back to acquisition to *find* the tool.
> 
> That is a different problem than *wrapping* the returned tool to give it
> place (for security, for forward compatibility, whatever):  if the tool
> implements 'Acquisition.interfaces.IAcquirer', then it *needs* wrapping,
> whether that is done via 'getToolByName', 'five.lsm', or some other
> voodoo-yet-to-be-written.  Failing to wrap objects that expect to be
> wrapped is a major party foul:  in fact, I would class that a
> showstopper for any final release of CMF 2.1.
> 
> Utilities that don't expect to be wrapped had better fall into one of
> the following categories:
> 
>   - They shouldn't be used by untrusted code at all (i.e,, all their
>     methods are declared private).  Such a utilitiy might be registered
>     as a "policy hook" for some other framework:  note that it would
>     *not* be possibile to *configure* such a utility TTW using "stock"
>     Zope2 ZMI patterns.
> 
>   - Or they have no expectation that Zope2 protects them (i.e., all
>     their methods are public).  Such utilities would either perform
>     their own security checks, *using a passed in context object*,
>     or would provide services which did not require any protection.

Perhaps it should be a view instead of a utility if such security is
needed.

Wichert.

-- 
Wichert Akkerman <wichert at wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.