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

Reply via email to