Rob Miller wrote:
i'll add yet another "me too" to this chorus. removing getToolByName has
become considerably more trouble than it's worth. currently, i see basically
two options being suggested:
- adding (and then living with) yet more code in Five, which changes the
behaviour of clean, well established Z3 idioms in order to support Z2
components which require acquisition.
- undeprecating an extremely widely used, intended-to-be-future-proof Z2
idiom, which would allow us to interact more simply and predictably with
existing Z3 utility lookup code
i guess it's pretty clear which one i support. ;-)
For the record, my personal preference was to *not* deprecate
getToolByName (yet), but to allow the use of getUtility and to have
getToolByName use getUtility internally. This would encourage a more
consistent API (as we develop new "proper" utilities) and eventually
we'd be able to move tools out of content space, with getToolByName
providing a (perhaps eventually deprecated) backwards compatible alias
for older tools that graduated to utilities.
When we first discussed this, no-one had thought about the acquisition
dependency, I think. If it were so that no tools really dependent on
acquiring things to function, I think that the above would have been a
viable and forward-looking solution. It may yet be, but it seems the
debate at this point is, "can we make utilities be
acquisition-independent" and if not, do we go for a stopgap measure that
may cause more problems than it solves, or do we need to wait.
Also, having used the new API (import interface, use getUtility) I much
prefer it to getToolByName. But that's just a personal preference. :)
Martin
_______________________________________________
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
