-----BEGIN PGP SIGNED MESSAGE-----
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.
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v188.8.131.52 (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