Previously Tres Seaver wrote:
> Alec Mitchell wrote:
> > On 4/15/07, Martin Aspeli <[EMAIL PROTECTED]> 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
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
See http://collector.zope.org/CMF for bug reports and feature requests