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:
>>>> We have to decide which way to go. I prefer c) if it works, b)
>>> 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
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
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.
Zope-CMF maillist - [EMAIL PROTECTED]
See http://collector.zope.org/CMF for bug reports and feature requests