On Jun 22, 2009, at 2:51 PM, Martijn Faassen wrote:

> 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).

They wouldn't. They don't use the URL traversal code. Non-URL  
traversal code would move to zope.tales. zope.container would depend  
on zope.tales rather than on zope.traversing.


> 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.

OK.

>> 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.


OK.

Jim

--
Jim Fulton
Zope Corporation


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

Reply via email to