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

_______________________________________________
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to