On Sep 26, 2006, at 3:00 AM, Stephan Richter wrote:

Hello everyone,

the following helper functions in zope.app.component do not work well with the new registry concept of bases: getNextSiteManager, queryNextSiteManager,
getNextUtility, queryNextUtility.

They work find in the case of a hierarchy, which is the default case.

Those methods expect a simple lookup tree, where the first base of a local registry is the registry its parent's site manager's registry or the global
registry; in other words, always the first base is selected (line 45).

Yup.  They only support hierarchies.

I started using the baseregistry,

Where is this documented?

I commonly add the base registries at the
first position, since I want them to override the global and other parent
registries. Doing so breaks all components that use the above helper
functions. Here is the solution I am going to check in later today:

- get/queryNextSiteManager

These functions will be deprecated, since they simply make no sense with the current design of the registries.I have checked the core code and they are not used anywhere except for queryNextUtility. I suspect the same to be true for all 3rd-party code as well, so that deprecating them should not really
hurt anyone.

You can't deprecate them without providing an alternative. I want to see a proposal for that.

- get/queryNextUtility

They are still very useful and their extensive use in the Zope 3 core code is
proof of that. Luckily their fix is simple. Instead of using
get/queryNextSiteManager to look up the next registry, we simply iterate through all the bases of the closest site manager until an answer is found.

That is a solution. I'm not sure it is the best. It won't handle more complex object graphs, such as diamonds correctly.

This way the lookup pattern will work as before and supports the new usage
pattern. I have tested this fix and it works for my code well.

The really big question is: Is that change worth porting to the Zope 3.3

Absolutely not.  It is not a fix, but a new feature.

It really is a serious bug that will cause people painful error
messages that are hard to understand. Also, it prevents people from using
Zope 3.3 and z3c.baseregistry.

I can understand that it is a problem for baseregistry.

Thanks for reading and any comments you might have!

The right way to address this problem, imo, is probably to implement the planned component super concept. This would provide:

- A more general solution,

- Possibly faster (because it is more general and can be more aggressively optimized),

- Handle more complex object graphs of the sort likely to occur when multiple base registries are used.


Jim Fulton                      mailto:[EMAIL PROTECTED]                Python 
CTO                             (540) 361-1714                  
Zope Corporation        http://www.zope.com             http://www.zope.org

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to