[Zope-CMF] Re: [dev] unresolved site manager related issues

[Alec Mitchell]

On 4/15/07, Martin Aspeli <optilude at gmx.net> wrote:
> Alec Mitchell wrote:
> > On 4/15/07, Martin Aspeli <optilude at gmx.net> 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
> other cases.

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
> implementations.

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
entirely.

Alec