yuppie wrote:
I'm judging by the solution itself *and* by the fact that we made a
decision long ago and released a beta based on that decision. We should
reverse that decision only if we are sure it was a mistake.
I think it was a mistake. It's ok, we all make mistakes. It's good that
we caught it before a final release.
Why a mistake? Because some CMF tools were apparently not ready to be
looked up as pure Zope 3 utilities yet. They depend on their acquisition
context. That's something the Zope 3 CA (deliberately or not) simply
doesn't give you. Kapil's also right when he says that utilities by
principle are context-less components.
the reason why a) was proposed is that the current usage isn't about
adopting the zope3 api, its subverting its usage and meaning by
introducing context dependencies where there were none before. a
utility is context independent, the majority of cmf tools are not.
I still don't buy that context argument. Utilities and tools both are
used in the 'context' of a site.
You just gave the definition of a tool, not the one of a utility.
The only difference is how the
knowledge about the site is used: Just for lookups or also for
acquisition wrapping.
If a tool needs to get to the site object in order to operate, it might
not be such a good idea to convert it to a utility. It might make more
sense as an adapter... What I'm saying is that the "all tools are
utilities now" assumption might've been a bit too naive.
On the other hand, there are valid use cases for accessing the site
object. Acquisition is only one method here and it happens not to be
supported by the Component Architecture. So it seems those tools aren't
ready yet, though fortunately the evolution towards a different way of
looking up the site object is simple; until then we also have a simple
fix (undeprecating getToolByName).
instead of introducing implicitness into the zope3 apis that imo
defeats the purpose of using them in the first place, we should fix
our tools so they can be used with the zope3 api and are not
contentspace/context dependent, and till they are so continue to
access them as we have been. a clear migration path that adheres to
this principle was outline in a).
I can see why you want to do it this way around, but I can't see why
switching first to utility lookups and changing the implementation later
is a mistake. I'm not aware of any problems that can't be resolved by
improving the site managers / registries.
At this point I don't either. All I know is that you're creating more
and more code (and dependencies) just to get getUtility() calls working.
Code, as you know, has the tendency to sit around forever. By
introducing this Franken-ComponentArchitecture-with-Acquisition system,
you'll not only increase the maintenance burden on your part, you'll
also taint an API that has been pretty predictable and clear before. I
would also bet that the existance of this hybrid will actually slow down
the evolvement process, as there will be no apparent reason to refactor
tools not to depend on acquisition anymore.
--
http://worldcookery.com -- Professional Zope documentation and training
_______________________________________________
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests