Hey, Thomas Lotze wrote:
zope.site.hooks is a rather light-weight module that is concerned with the concept of a current site, where the notion of a site is used in the same sense as in zope.component, which actually prefers to only talk about a component registry. In contrast, the rest of zope.site deals with local site managers and container stuff including the implementation of folders.
IMO it would be interesting to have the concept of the current site available separately from the rest of zope.site with its 30 dependencies. (For example, zope.browserresource demonstrates how with the present zope.site the need to know the current site in order to determine a URL leads to a dependency on the ZODB.)
+100 if this makes site-aware code have less dependencies. One can really get rid of a *lot* of dependencies this way.
I would propose moving zope.site.hooks to zope.component.hooks if it wasn't for its use of zope.security in order to remove security proxies in two places. These places have rather old comments that suggest reconsidering the handling of security proxies at some point. Right now, the code that removes the proxies is needed but I'd like to raise the question whether we should try to get rid of it. If there's no objection to this goal, I'd like to investigate what it would take.
We could investigate two options: * just removing that code that remove proxies and sees what happens to significant Zope 3 code bases. Risky. * alternatively, putting in an optional dependency on zope.security in zope.component. If zope.security proxy is importable, try removing the proxies, otherwise don't. Regards, Martijn