Martijn Faassen wrote: > Thomas Lotze wrote: >> 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.
That's what I thought ;o) > We could investigate two options: > > * just removing that code that remove proxies and sees what happens to > significant Zope 3 code bases. Risky. To begin with, compat-tests of a number of ZTK packages and a lot of the packages under review for the ZTK fail if I do that. This is why I said the code is currently needed. Typically, this has to do with something about interactions not being available to code like zope.component.subscribers(). > * 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. I thought about that one briefly, but I don't like it because it introduces at least some knowledge about the security concept to zope.component. While I can't follow why others consider an optional dependency bad from a technical point of view such as usability on GAE, I think zope.component is so low-level that we should value its conceptual clarity greatly. -- Thomas _______________________________________________ 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 )