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

[Philipp von Weitershausen]

yuppie wrote:
> Philipp von Weitershausen wrote:
>> yuppie wrote:
>> Kapil's also right when he says that utilities by principle are 
>> context-less components.
> 
> By principle all Zope 3 code might depend on setSite to work as 
> expected.

setSite() is something that influences the place (= registry) that we 
look up the utilities from. It doesn't influence the "context" of the 
utility because tilities have no context. Sure, utilities might be local 
and even persistent. But that is a registration detail, not an 
implementation detail.

The name "site" in Zope 3 is confusing. "Place with component 
registrations" is better. So, let's pretend setSite() was called 
updateCurrentComponentRegistryFromPlace(), it becomes pretty obvious 
that it has nothing to do with what the utility does. All it does is 
tell the Component Architecture which component registry to look up 
things. The fact that this registry happens to be associated with a 
place in the object hierarchy is completely irrelevant to the Component 
Architecture.

> We just don't pass that 'site context' explicitly to the 
> component as in Zope 2.

Right. The utility doesn't even *get* the context (and it shouldn't need 
it.) And in Zope 2 we don't pass the context in either. The tools get it 
by doing aq_parent(). This should be converted to a lookup, because it's 
not about the hierarchy that the tool happened to be placed in, it's 
about getting one very specific object: the CMF site.

>>> 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.
> 
> By 'site context' I don't mean an Zope 2 acquisition context or an 
> adapter context. I mean the site specific local environment that is 
> usually looked up based on setSite or provided by CMF tools.

Utilities shouldn't care which "site context" they've been registered 
at. If they want a specific object like the CMF site they should look it up.

>>> 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.
> 
> Of course CMF tool interfaces have some methods we would not add to a 
> new utility interface. But most of them would become views, and as long 
> as we pass in the REQUEST explicitly they are still valid utility methods.
> 
> I'm not aware of any tool methods that should be converted to site 
> adapters. Most tools use the 'site context' just for the security 
> machinery. The other reason why tools needed the context was looking up 
> other tools, but that is obsolete in CMF 2.1 beta. I consider every 
> other usage of the acquisition context a bug.

Good. Then fix those "bugs" and we no longer need any acquisition 
wrapping of local utilities at all (and it should be ripped out of 
five.localsitemanager again). This would, of course, be an acceptable 
solution.


-- 
http://worldcookery.com -- Professional Zope documentation and training