On Sep 26, 2006, at 3:00 AM, Stephan Richter wrote:
the following helper functions in zope.app.component do not work
well with the
new registry concept of bases: getNextSiteManager,
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
registry is the registry its parent's site manager's registry or
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
registries. Doing so breaks all components that use the above helper
functions. Here is the solution I am going to check in later today:
These functions will be deprecated, since they simply make no sense
current design of the registries.I have checked the core code and
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
You can't deprecate them without providing an alternative. I want to
see a proposal for that.
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
through all the bases of the closest site manager until an answer
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
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
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
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
- 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