Tres Seaver wrote:
> Re: Empty path elements:
> Zope2 uses them at the beginning of a path to indicate traversal from
> the root.
Sure, in restrictedTraverse and the like. But not in TALES expressions.
While you can start a TALES expression on a /, the empty path element at
the beginning stands for the global namespace. Hence, path:foo/bar and
path:/foo/bar are identical. Specially, you still have to write root/bla
or /root/bla to traverse from the root object.
> -1 to dropping that case (it is the one which makes
> '/foo/bar' behave orthagonally). Havinng blank elements work as no-ops
> also makes them behave predictably: this is what command shells (sane
> ones, anyway) do with them. E.g.:
> $ ls /path/to//foo
> yiels the same results as:
> $ ls /path/to/foo
> So -0 to dropping the current blank traversal behavior at all.
> Therefore, +0 to modifying Z3's version to allow the same behavior (I
> think Zope2's version is more correct).
I would tend to agree, however, Fred must've had a reason when he added
the check for empty path elements in zope.tales.expressions:
26551 srichter class SubPathExpr(object):
9658 matth def __init__(self, path, traverser, engine):
9637 matth self._traverser = traverser
9658 matth self._engine = engine
9637 matth # Parse path
9658 matth compiledpath = 
9658 matth currentpath = 
9658 matth for element in str(path).strip().split('/'):
26722 fdrake if not element:
26722 fdrake raise engine.getCompilerError()(
26722 fdrake 'Path element may not be empty in
%r' % path)
r26722 unfortunately doesn't have a log message that might hint at the
reason. It does feature an extensive test
(testEmptyPathSegmentRaisesCompilerError) for this change though.
Perhaps Fred can shed some light on this issue? (CCing him)
> Re: calling primitive types which are at the end of a path expression.
> They should be called, as should any other callable at the end of a path
> expression; anything else is a hard-to-explain bit of special case
> hackery. The ZPT spec has *always* read so. +1 to fixing both / either
> Z2 or Z3 to make this uniformly so. BBB be damned in this case, as the
> behavior (not calling the primitiive type) is contrary to spec.
Right. Basically, we'd be fixing a bug because the current Zope 2
behaviour is contradicting spec. Too bad this behaviour is documented in
a test... oh well, tests can have bugs, too. I will fix the test in Zope
2.10 to work with Zope 3's (correct) behaviour. I should probalby also
fix Zope 2.9's behaviour if we consider this a bug?!?
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -