[ZPT] Re: RFC: TALES adapters and TAL/Tales variable namespaces
Evan Simpson
evan at 4-am.com
Fri May 21 12:56:10 EDT 2004
Jim Fulton wrote:
> One disadvantage I see with the cast notation is that it's
> a bit jarring in:
>
> a/b/(adapter)c/d
>
> as the adapter is applied to a/b/c. The order just doesn't
> seem quite right.
Unless I'm misunderstanding something fundamental here, in the TALES
context an adapter is essentially a function accepting a single
argument. The "adapted" object that results from applying the adapter
function is either used directly or further traversed. All of the other
qualities that make up an Adapter (how it's registered, that it supports
ITALESAdapter, etc.) are irrelevant to its use in a TALES expression.
Given all that, why do we need to shoehorn the adapter's name into the
same path segment as one of the traversal names? The above looks much
more natural to me as one of:
a/b/c/(adapter)/d
a/b/c/*adapter/d
a/b/c/adapter()/d
a/b/c/adapter:/d
Note that the latter two forms allow for additional arguments. While
not applicable to single-argument adapters, this is certainly a useful
feature if we don't restrict the syntax to adapters only. In
particular, evan-pathprefix-branch uses the colon syntax to allow
applications such as "a/b/c/index:2/d" and "a/b/c/call:x,y/d". This
same scheme can easily subsume adapters in either or both of two ways:
adapter as prefix, and adapter name as argument to a prefix.
tal:define="prefix foobar adapter:foo.bar"
tal:content="a/b/c/foobar:/d"
...or...
tal:define="prefix A builtin:adapters"
tal:content="a/b/c/A:foo.bar/d"
Cheers,
Evan @ 4-am
More information about the ZPT
mailing list