On Fri, Mar 25, 2011 at 9:58 AM, Martin Aspeli <optilude+lists@gmail.com> wrote:
On 25 March 2011 13:17, Jim Fulton <jim@zope.com> wrote:
On Fri, Mar 25, 2011 at 4:24 AM, Wolfgang Schnerring <ws@gocept.com> wrote:
...
2. zope.component has two entry points, the global site registry and the current registry (getGlobalSiteManager and getSiteManager). The current registry can be anything, or more precisely, you can call getSiteManager.sethook(callable) and provide a callable that returns the current registry.
I think to provide test support for zope.component (i. e. generally, at the "library level"), we need to support both entry points.
Why? Why would someone care about anything other than the current effective configuration.
Agree. There is a problem in that provideAdapter() and friends don't use getSiteManager() - the always use the global site manager. And there are parts of zope.component that use module level variables directly, ignoring hooks.
These are meant to work this way. If you want to do local configuration, you should explictly select the relevent registry/manager or call getSiteManager and use the result.
-- but anyone could at any time call getSiteManager.sethook to change it!
Seriously? Nobody calls that but deep infrastructure code.
People do call zope.site.hooks.setHooks() sometimes, though, e.g. upon traversal.
This was never meant to be an application-level feature. I find the notion that people would call these dureing traversal to be disturbing. Are you sure you're not confusing this with setSite? Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton