On 4/15/07, Martin Aspeli <[EMAIL PROTECTED]> wrote:
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.
I suppose it depends on how you look at it. If we agree that the way to
get tools out of content space is to make them utilities, and we want to
be able to promise the normal semantics for global and local utilities.
In that case, moving to getUtility as the API and interfaces as keys
seems to be a long term goal. As for consistency, call it aesthetics,
but I know it's becoming quite hard to explain to new developers that
various things are semantically similar, but there is an old way that
applies to cases X, Y and Z, and then a new way that applies to all
It's a nice idea, but we're just not there. CMF tools aren't used in
the way that utilities are intended, they are not utilites, and using
the utility machinery to look them up doesn't make them into
utilities. Many, if not most, tool methods take a context argument of
some sort, most of these should probably be implemented in adapters,
which would give much more flexibility in customizing/overriding
behavior and would avoid a lot of the issues that we're currently
seeing. Those that also lookup or require a request should of course
be implemented in views. Things like the registry of actions (but
probably not the lookup of actions available on an object) and the
undo tool make sense as utilities, but a lot of the rest just doesn't.
Rather than refactor these things into appropriate sets of components
(which is admittedly a tremendous undertaking and a compatibility
nightmare), we seem to be taking a shortcut that provides no real
benefits and a lot of potential headaches.
Anyway, the point here is the consistency/flexibility/ease of migration
in the future benefit vs. the cost of time/complexity and indeed whether
it's possible to achieve all the benefits with the current tool
We're creating migration pain right now. When you consider that many
if not most of these "utilities" will vanish or change dramatically as
they are factored into more appropriate and flexible components, I see
little in the way of eased future migrations. I have yet to see an
indication of what the benefits you refer to above might be. Keep in
mind that I am a tremendous proponent of the component architecture
within Zope and Plone, as are most of the people making these
objections. I think there are a huge number of potential benefits to
componentizing things, I just don't see them here. I'd go so far as
to say that these changes don't really seem to be "componentizing"
anything, just moving and renaming things.
This was all nice and pretty when no-one had thought that
tools-as-utilities needed to be wrapped at all. If that'd been the case,
we'd just be having a deprecation warning discussion. :)
I'd be very surprised if anyone thought that the wrapping of tools
would be unnecessary in this scenario. There would indeed be nothing
wrong with using the utility machinery to look up tools if the
addition of acquisition didn't break the local component registry, but
that doesn't mean there'd be any non-aesthetic benefit to the change
either. There's nothing wrong with making changes for the sake of
aesthetics, but breaking applications (both by deprecating a
fundamental API, and with what turns out to be a pretty big
acquisition mess) for the sake of aesthetics is another matter
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests