Jim Penny wrote:
And why would I expect a ZPT person to have a basic knowledge of data

In my view, this whole idea is primarily aimed at programmers. I fully expect that non-programmer ZPT people will be able to ignore this stuff, apart from being handed a small set of idioms by the programmer. Paths that can make use of these features are going to be constructed by programmers, and used as black boxes by ZPT people.

The driving rationale behind most of the prefixes that I implemented is to provide explicit spellings for things that have bitten myself and other programmers in practice. 'key', 'item', and 'attr' let us specify access methods when traversal magic fails (eg. method names clashing with keys, no way to access sequence items), and 'call' lets us traverse through simple data-access methods. 'var' is just a less-cryptic version of '?'-prefixed path elements.

Several of your objections/suggestions involve the distinction between a string and a name, as in:

x/index:'foo'  -->  x['foo']
x/index:span_of_int  ->x[span_of_int]
x/index:foo    --> x[foo]

I'd rather not introduce additional punctuation (quotes or parens) if I can help it -- TAL and TALES both have a tradition of minimalist syntax, and it keeps parsing simple. Also, as soon as you add delimiters, you add quoting issues, and TALES has enough of those already.

call: well, you have said that arguments are allowed, and must be only
variable names.  What is the reason for this?

To keep things simple. There's a clearly visible slippery slope here, and I hope to stay off of it, since it leads to full-on Python in the middle of a path, which would be a nightmare. Names-only takes care of the most common case, while allowing for dead-simple parsing (arg.split(',') then validate each name).

Does using call: explicitly erase all magic name bindings (I hope so)?

I don't know what you mean, here.

fmt: is most irregular.  First, it reverses the pattern of all the
others and makes the stuff to the left the parameter.  This may be OK
for your intended audience.  It may also confuse them totally.  Why
x/fmt:%.2f and not x/fmt:'%.2f'?   As it stands, it takes either
expression fragments starting with % or function names.  Can I define my
own functions, if so, how/where?

'fmt' is a quick-and-dirty implementation, and most likely to change. It was almost certainly a mistake to conflate the standard formatting functions with Python string formatting. I don't agree that it reverses the pattern, though -- to me, it's "apply *this* formatting operation to the current object", much like 'key' is "fetch *this* key from the current object".

One of my to-do's on this idea is syntax allowing prefix strings to be associated with an implementation within a template, possibly overriding the default associations. In particular, this would allow you to make a prefix for a collection of your own functions.

Finally, can we come up with a better term than prefix.  In conventional
terminology, most of these are infix operations, except call, which may
be a purely postfix.

'prefix' refers to the syntax, not the operations. In my source code comments, I refer to "prefixed path elements". A better name would be welcome :-)


Evan @ 4-am

Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to