[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