Gaaa.  As I did deeper, it's even more muddled that I feared.  I'll  
start a separate thread.


On Jun 21, 2009, at 8:48 AM, Jim Fulton wrote:

> On Jun 21, 2009, at 5:36 AM, Christian Theune wrote:
>> On Sat, 2009-06-20 at 13:04 -0600, Shane Hathaway wrote:
>>> Jim Fulton wrote:
>>>> Why?  traverseName is part of's  
>>>> implementation.
>>>> Now it's oddly split off in a very separate package.
>>> The publisher traversal code is very similar to the code in
>>> zope.traversing, so I thought the best thing to do is put it in the
>>> same
>>> package as zope.traversing, so that traversal would be maintained
>>> in one
>>> place.
>> I think there's a valid goal around here. Publisher traversal and
>> traversal as used in templates have two different implementations  
>> that
>> partly overlap at some points and its hard to explain why there are
>> two
>> of them.
>> I'm not sure whether we can get a single unified implementation, but
>> for
>> me that would be nice.
> I don't agree. The semantics are different. For example, you often
> want to traverse to things in a template that you don't want to expose
> via URL.  We currently (or last time I checked) expose ++resource+
> +name in URLs and this is a bug.
> The only place this traversal code is used outside of publication is
> by the browser menu code that tries to traverse to a menu item to see
> if it is accessible to the user.  This was to avoid having to put
> security declarations on menu items (a worthy goal) but we've found
> that this entailed far too much expense and complexity.  I'm not sure
> anyone is even using this menu code any more and if they are, I bet
> they are or should be making explicit security declarations.
> Jim
> --
> Jim Fulton
> Zope Corporation
> _______________________________________________
> Zope-Dev maillist  -
> **  No cross posts or HTML encoding!  **
> (Related lists -
> )

Jim Fulton
Zope Corporation

Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to