Jim Fulton wrote: [snip[
I made it possible to override proxying by overriding the proxy method. At this point, I think zope.app.publication provides a pretty reasonable base class for custom publication implementations, although the module arrangement could be made a bit simpler.
Cool. :)
I propose the following:
In phase 1 reduce the scope of zope.traversing:
- Move path traversal code to zope.tales
I'm very much +1 for anything that moves ZPT-only traversal to places where it's less likely to confuse the reader of the code into thinking it's URL traversal.
- Move the URL traversal code used by zope.app.publisher.menu to zope.app.publisher.menu. Refactor it to use the request.publication. Deprecate definition of menu items without permissions.
I'm worried about how this affects dependencies. I wouldn't want, say, zope.container, zope.app.pagetemplate and zope.site to start depending on zope.app.publisher where now they depend only on zope.traversing (which is much more lightweight in the dependency department). If you can do this without making zope.container depend (indirectly) on zope.app.pagetemplate and the like, or, say, zope.site on zope.contenttype, then I'm +1. This means that we shouldn't make zope.traversing depend on zope.app.publisher at any stage, as this would completely screw up all graphs. The dependency for backwards compatibility should ideally be a loose one, not marked in the setup.py dependencies and only required if backwards compatibility is needed.
Thoughts?
Please do watch those dependencies... The z3c.recipe.depgraph buildout recipe can help you generate dependency graphs. Please watch the scc graphs to see whether you aren't inadvertently creating more cycles. Regards, Martijn