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 needed. 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 - [email protected] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
