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

[Jim Fulton]

Stuart Bishop wrote:

> 
> 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" />

Note that no one has sugested this so far. Perhaps you meant:

  <input name="key" tal:attributes="value
      request*IObjectSessionData/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" />

Except that we'd probably provide a shorter name, as in:

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

This is an important point.

>
> 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.

Which is why I'm not in favor of the lst syntax.

 > 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 ;) ).

Right (I was mistaken in my comment in the original proposal.)

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

Not sure what you meant by "adapt" in this.

> <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.

I think that, for lots of folks, the hairiness comes from making path
expresssions that expressive in the first place. At that point, it's
probably better to just use a python expression:

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

Another problem with using a generic call mechanism is that the adapter
names have to be defined in the regular variable namespace.  I'd like to be
able to predefine some standard adapters for Zope 3 without adding new names
to the regular variable namespace.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org