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
> 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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -