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 _______________________________________________ Zope-CMF maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests