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

[Philipp von Weitershausen]

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