-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. - Or some mixture of the two. Any use of 'security.declareProtected' in the class of the tool mandates that the tool be given "place" for Zope2 security purposes, even if nothing else needs wrapping. Trying to come up with an "elegant" way to avoid the necessity of wrapping is silly at this point: it isn't even "better" to try to make Zope3-style wrapping (the ILocation stuff) equivalent, because we will have to support implementations which don't know or care about Zope3 indefinitely. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGIv4a+gerLs4ltQ4RAhXAAJ9HPCBZL+YKdjZR40/RTG9oUy+yEQCeM6+l f6il2a1cqNgkaGmtVJVptyY= =rgN1 -----END PGP SIGNATURE----- _______________________________________________ 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