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

[Godefroid Chapelle]

Jens Vagelpohl wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> On 10 Apr 2007, at 10:30, yuppie wrote:
>> Currently non-five.lsm site managers don't work in CMF, see this thread:
>>
>> http://mail.zope.org/pipermail/zope-cmf/2007-March/025817.html
>>
>>
>> Proposed solutions:
>>
>> a) reverting most 'tools as utilities' changes (Kapil)
>> http://mail.zope.org/pipermail/zope-cmf/2007-March/025817.html

I'd like to mention this is not just Kapil proposal. Other people at the 
sprint were involved in the discussion that lead to Kapil's mail. 
Actually, that mail was written and reviewed by multiple persons.

>>
>> b) supplementing five.lsm (Hanno)
>> http://mail.zope.org/pipermail/zope-cmf/2007-March/025822.html

I am not sure if the following has been made clear so I'll try to 
explain it again.

The current implementation of zope.component.registry.Components 
accesses the internals of the registries instead of using external APIS 
(I suspect this is for performance reasons). This implies that there are 
only two ways of implementing automatic acquisition-wrapping of utilities :

- patch the Z3 registry itself in order to make all registries 
acquisition-aware as done currently in Plone 3.0

http://dev.plone.org/plone/browser/plone.app.kss/trunk/plone/app/kss/five_lsm_patch.py

- have all local component registries (including five.lsm) derive from a 
common mixin class that implements 'queryUtility', 'getUtility', 
'getUtilitiesFor' and 'getAllUtilitiesRegisteredFor' methods.

This is easy to do (I had an implementation in 20 mins).

However, in order to use with five.lsm components that are valid in Z3, 
we would need to "fix" :-S them with conditional imports.

The above were facts, lets move to my opinion ;-)

Both solutions do not smell very good but it would not be the first time 
we live with bad smells.

However, my main concern regards the strategy used to get rid of tools 
in content space. I think that we inverse the order of things to do : we 
try to get rid of getToolByName API before getting rid of dependency on 
acquisition.

Today, we are far away enough from the removal of tools from content 
space that we need the acquisition magic in five.lsm (correct me if I am 
wrong) to make most CMF tools work correctly.

We first need to fix the most fundamental tools so that they can be used 
without acquisition (iow as pure utilities). When they are fixed, we can 
switch their calls from the getToolByName proposed in (a) to the 
getUtility we all wish.

By fixing the implementation/use of those tools, we will have explored 
most of the consequences of the 'migration'. We can at that moment 
deprecate the getToolByName API as we will be able to give advices and 
patterns how to fix, to people that will still be relying on 
getToolByName acquisition wrapping.

>>
>> c) improving five.lsm (Rocky)
>> AFAICS this is an other attempt to resolve the same issue:
>> http://mail.zope.org/pipermail/zope-cmf/2007-March/025708.html
>>
>> We have to decide which way to go. I prefer c) if it works,  b) otherwise.
> 
> Same here. c) first, then b). Strongly against a).

Before the sprint, I have spent more than one day exploring (c) Rocky's 
proposal  and did not get to anything satisfactory. The 
zope.interface.adapter.AdapterRegistry would need to be 
acquisition-aware. IOW, we would once again pollute Z3.

I explained here above why (b) is not a solution I like and why I 
support (a).

Could you explain why you are strongly against (a) ?

> 
> jens

-- 
Godefroid Chapelle (aka __gotcha)- BubbleNet  http://bubblenet.be