[Zope-dev] RFC: ZTK custom publications, zope.app.publication, and zope.traversing

[Martijn Faassen]

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