[ZPT] Re: ZPT digest, Vol 1 #62 - 1 msg

[Guido van Rossum]

> I am just afraid of multiplying the number of special syntax cases. We should
> avoid to approach the TMTOWTDI by not being careful enough.
> 
> What I mean is that it is easy to understand why the 'exists' construct is
> unique to path.
> 
> It is may not be so obvious for the 'if' construct. Are there reasons to not
> extend it to other expression types ? I imagine cases where a Python expression
> returns None or '' and where it would be useful to have the 'if' construct. And
> even if the following expression seems stupid (if string:) I see no reason to
> forbid it.
> 
> I have read the TALES specification again and have the feeling that, under
> prefixes, orthogonal concepts are classified as same things.
> I think that the distinction between prefixes responsabilities should be made
> more clear.
> It would also allow to have a more clear syntax description.
> 
> I propose the following as a summary of the different documents : expression
> types, path modifiers, expression result modifier, action modifier
> 
> For example,
> 
> three expression types : string, path, python
> 
> two path modifiers : nocall, exists as described in
> http://dev.zope.org/Wikis/DevSite/Projects/ZPT/PathExpressionVariants
> 
> one result modifier : not
> 
> action modifier : if
> 
> Finishing this description, I feel uneasy about the role of the 'if'. As
> described above it has u fuzzy poistion between TAL and TALES.
> If I understand the points, could the 'if' construct be explained as follows ?
> 
> 'if' acts as a function changing the boolean value true to 'execute TAL action'
> and the boolean false to 'cancel TAL action'.
> Those two 'things' could be seen as special TAL constant values.
> 
> But then, what does happen when there are multiple TALES expression in a
> multiple TAL 'define' ? I would like to avoid the situation where the if
> construct can be used in certain TAL action and not in others...

I agree with you -- this use of the TALES prefix for very different
purposes has made me feel uneasy, too.  Unfortunately, I don't have a
good feel yet for how we could fix this: we could push more of this
functionality into TAL, or we could diversify the TALES syntax, or ...

For now, I think the only thing we *can* do is continue on the road we
took, but keep in mind that we may have to rethink the TALES syntax
once we have more experience with using it.

--Guido van Rossum (home page: http://www.python.org/~guido/)