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

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to