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

[Stuart Bishop]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If we want to use a concrete example for this, getSession will be
replaced with an Adaptor (which wasn't possible when it was written).

<input name="key" tal:attributes="value
	IObjectSessionData*request/product.id/key | nothing" />

<input name="key" tal:attributes="value
	(IObjectSessionData)request/product.id/key | nothing" />

<input name="key" tal:attributes="value
	IObjectSessionData(request)/product.id/key | nothing" />

I personally have no trouble parsing any of there. I suspect
the first would be most acceptable to non-programmers, and least
acceptable to Python programmers who associate magic punctuation
with Perl ;)

I would like to see the last working as a generic function call
mechanism. I don't see how the expression a/b(c/d, e/f)/g/h (from
the RFC) is in any way ambiguous. The only way I can see of
getting something other than python:a.b(c.d, e.f).g.h is if you
expect it to somehow work like a the shell glob expression
a/b{c/d, e/f}/g/h (which is just wrong ;) ).

<input name="key" tal:attributes="value
	adapt/IObjectSessionData(request)/product.id/key | nothing" />

<pre tal:content="format/currency(here/amount, width=10)" />

Would the hairiness be if you use something other than a path expression
in the call (as ',' is valid in python: and string: expressions), so
the following would not work:
	tal:content="format_tuple(python: 1,2,3,4)"
(but python: (1,2,3,4) could be made to work)

Possibly using ';' instead of ',' to separate arguments would solve
these issues? Or just don't let anything other than simple path
expressions be used as arguments.

- --  
Stuart Bishop <stuart at stuartbishop.net>
http://www.stuartbishop.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFArdS7AfqZj7rGN0oRApsEAJ47Zj0UAMBx7d8I4tK0xx8qD342iwCeLmo5
cS43s3yBsbcKqp8rywufPwI=
=Ee20
-----END PGP SIGNATURE-----