[Zope-dev] Re: [ZPT] Re: RFC: TALES adapters and TAL/Tales variable namespaces

2004-05-21 Thread Ian Bicking
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.
That is indeed jarring, especially since c isn't an object, it's just a 
name, and a/b/c is the object in question.  This would look somewhat 
better with the current : mechanism, like a/b/c:adapter/d

My concern with this use of : was that it looked like it should be 
parsed like (a/b/c):(adapter/d), as opposed to ((a/b/c):adapter)/d -- 
maybe using something other than : wouldn't imply this grouping.  Or 
maybe if I got used to it the grouping would seem more natural.  I guess 
my intuition is that / binds more closely than : (even if there isn't 
any real precedence at all in TAL expressions).

--
Ian Bicking  /  [EMAIL PROTECTED]  /  http://blog.ianbicking.org
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )


[Zope-dev] Re: [ZPT] Re: RFC: TALES adapters and TAL/Tales variable namespaces

2004-05-21 Thread Evan Simpson
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
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )