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

[Balazs Ree]

On Wed, 11 Apr 2007 16:01:38 +0200 yuppie wrote:

> Godefroid Chapelle wrote:
>> Jens Vagelpohl wrote:
>>> On 10 Apr 2007, at 10:30, yuppie wrote:
>>>> 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.
> 
> Why isn't it sufficient to use a customized version of AdapterRegistry
> for five.lsm? If the direct lookup in the registry returns wrapped
> utilities, other site managers and registries don't have to be
> acquisition-aware. No?

Briefly, the direct lookup will not wrap the utilities precisely because 
it is a direct lookup and will bypass the code that is supposed to wrap 
them. I try to elaborate below. 


First: I am entering this thread a little late so sorry if I reply 
inconsistently. I was however a signer of the original document which 
thinks describes things pretty good and spent enough time on the issue to 
understand a bit about it. Taking the risk of repeating things said 
earlier in this thread, I attempt to summarize my points.

The root problem is that the z3 component lookup, in case site managers 
are chained, is accessing the data of the chained site managers directly 
and bypassing its code. Iow it does not matter whatever acquisition 
wrapping you add in five.lsm. If there is any other site manager that 
appears, and that is not inheriting directly from five.lsm (and why would 
it?), it will access the registry data from the sitemanager of five, but 
bypass the methods that would add the acquisition wrapping in five.lsm, 
and will use _its own_ methods for returning that data. Which means 
principles of object oriented programming are somewhat broken and 
actually if I had not spent a few days debugging this problem, I would 
not easily suppose or believe this even myself, but this seems to be the 
case.

This is precisely why, imo, the proposed solution for making all site 
managers acquisition aware and inherit code conditionally from five.lsm, 
is *not* the correct path to follow. Sure we could change the code of all 
our existing components that implement site managers. We could do this 
with KSS for example, and the breakage would be gone.

But then consider what happens if anyone else in the future, not knowing 
that from this moment it is illegal to use plain zope3 site managers, 
happens to implement one "as described in The Book", or happens to adopt 
some working code from plain zope3 userspace? The result will not only be 
that the code that depends on this new site manager will be broken, the 
effect will be that _all_ the code that uses _any_ getUtility lookup and 
depends on acquisition will be misteriously broken at once! This is kind 
of unexpected and will be very difficult to debug, it will happen 
inevitably, in both the core products and in custom site developments.

Of course the best solution would be neither a) b) or c), but if the z3 
component registry behaved in the expected way and would use not only the 
data but also the overwritten lookup methods from the classes that 
implement a given registry. I don't know if this would be easily achieved 
but I would suppose that this would not happen soon. There must be good 
reason why it is implemented this way and would be quite a big change to 
alter this. So what remains is that practically the site manager registry 
lookup code cannot be customized from any given site manager, because 
there is no guarantee that the methods will be used or not, because this 
depends on the site manager chaining.

Consequently we cannot use five.lsm either to add the acquisition 
wrapping in a consistent and transparent way, at the moment. At least not 
by overwriting the registry lookup code.



There is also another side of the story and this is that imo CMF or any 
other code that builds upon Zope, must respect its autonomy, ie, should 
not break plain z3 code or put additional restrictions on legitime 
constructions usage. There is at least an independent occasion where we 
discovered CMF is doing that (I believe this would deserve a thread of 
its own, briefly we have a plain zope3 product kss.demo that cannot be 
added from the ZMI any more, because we get a 'main_template not found' 
and of course we have no main template - the problem in this case is that 
CMF is overwriting something that has an effect in the entire instance, 
not only inside a portal where it has authority.)

So when choosing a decision, it would be also important to consider not 
causing a breakage or putting extra requirements on code that is 
otherwise legitime itself, because this is against the principle of 
modular programming.

Also it seems that the ultimate answer to "why this happens" is that 
because the z3 registry lookup is broken in this respect. Or to phrase in 
in a more fair way, Zope3 is not constructed to deal with the usecase of 
handling acquisition. Acquisition is raping Zope3, it seems. This is why 
maybe (I am not sure about this, but in fact others are proposing this), 
maybe, the best solution would be to try moving the acquisition logic out 
to a separate clean layer, and not trying to add it transparently to Zope.

-- 
Balazs Ree