Tres Seaver wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Philipp von Weitershausen wrote:
>> Hanno Schlichting wrote:
>>> I would say that all of Acquisition is dark implicit magic and something
>>> I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2
>>> I also expect the need to make the Zope 3 code Acquisition aware. One
>>> prime example are browser views, which I need to mix in Acquisition in
>>> order for them to work.
>> But Products.Five.BrowserView hides that particular detail from you, as
>> much as getToolByName could hide the acquisition detail when looking up
>> You're suggesting to introduce yet another package that's destined to go
>> a way at some point, while the same functionality is already available,
>> it only needs to be un-deprecated...
> +1 for removing the "across-the-board" deprecation of 'getToolByName';
> I find Kapil's argument convincing here. I think leaving the
> deprecation for the case where the API has to fall back to raw
> acquisition to find the tool is pretty reasonable, as it shows the user
> where the missing registrations are in her site.
> I'm not sure what impact that would have for the already-converted code
> which used to use the API. I can see value both in leaving it
> converted, as showing the Zope3-ish way, as well as in reverting some or
> all of it. For instance, perhaps we should consider reverting just
> those changes which look up acquisition-dependent tools, since the call
> site has now become required to manage the wrapper itself.
Do we have any idea *which* tools are "acquisition-dependent" and which ones
are not? By this, I mean which tools expect to be able to acquire things
from 'self', for example, not so much acquisition-dependent security around
tools being accessed TTW.
View this message in context:
Sent from the Zope - CMF list2 mailing list archive at Nabble.com.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests