-----BEGIN PGP SIGNED MESSAGE-----
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
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v18.104.22.168 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests