[ZPT] Re: TAL's lack of an else...

[Evan Simpson]

At this point, I've come to the conclusion that unless you really need a 
  conditional with more than two branches, the standard idiom is 
actually not bad at all.  As far as I can tell, those folks asking for a 
new construct have been doing so on philosophical/aesthetic grounds, not 
because they've had trouble writing a template without it.

 From now on, if anyone asks "why doesn't TAL have if/else", my answer 
will be: "it does, and it looks like this" followed by an example of the 
define/condition/not:condition idiom.  If someone wants to know about 
"elif", well, that's a different matter.

Fergal Daly wrote:
> At a guess (just a guess) it's not because they object to if/else in principle
> but because they couldn't find a nice enough syntax.

Good guess :-)  After kicking it around, we decided that tal:condition 
is technically sufficient, and that if it was painful in practice that 
we would hear about it, and that those who felt the pain most might have 
a reasonable spelling for it.

> In order to know that 2 or more blocks of XML are related, you either need to 
> label them somehow, wrap them inside another block (or put one inside the 
> other) or notice that there is nothing between them (nasty) or do something 
> else that I can't think of.

Right.  Comparing TAL to procedural programming languages is deceptive, 
since TAL has to live in an XML (-ish) world, and therefore has severe 
constraints on its syntax.  The current define/condition/not:condition 
idiom uses nesting, my proposal uses labelling, and I would be violently 
opposed to a spelling that depended on adjacency.

We spent a fair amount of time and thought trying to design a METAL 
feature that would allow switching among several "states" of a template, 
at both design time and run time.  The idea was that you could define a 
set of "dimensions" (bad name, I know) each of which enumerated several 
"states", and then have a nice UI to switch the template between states 
and alter design elements that differ between states.  For example, you 
could have and "Authentication" dimension, with states "None", "Normal", 
and "Admin".  You could then edit the user's menu choices for each 
state, and the system would automatically place METAL attributes on the 
smallest set of affected elements.

This was abandoned because it was too complicated, and required too much 
support from the design client.