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

[Evan Simpson]

Jean-Michel Hiver wrote:
> I don't know what the others think, but I think this is looking like an
> ugly mess.

I think most people on the list agree with you, which is why it never 
went anywhere last time :-)

Fergal Daly wrote:
 > I'm not so sure you should overload tal:condition to have a 1
 > arg and a 2 arg meaning. I think it makes it trickier to parse.

Actually, not so bad.  If you split(), get a list of more than one 
element, and the first element is a valid name, you've got a grouped 
condition.

> you should have put the "Not First" line last, I'm sure that's what you 
> would have done if you were writing and if/elsif/else in Python. Actually in 
> an if/elsif/else language that whole thing would have had the loop outside 
> the condition group but maybe that was what you were showing?
> 
> I find condition groups clever but a bit weird and I think you can do 
> confusion stuff like interleaved if/elsif/elses and putting unconditional 
> stuff in the middle of conditional control structures

I *couldn't* put the "Not First" line last, because my (invisible) 
specification for the output says that if "Not First" is output, it 
needs to be above "Last".  Putting in "unconditional stuff" and stuff 
that depends on different conditions than the surrounding markup is the 
kind of thing that template sometimes *do*.  Both of these were 
*motivations* for the design of condition-group, since they are huge 
differences between how templates work and how typical procedural code 
works.

In typical procedural code, you can often take code that has a lot of 
if/elif/else/switch branches with shared code and rearrange it by using 
temporary variables or refactoring the shared code into a function.  In 
a template, this doesn't work for two reasons -- first, the output of 
the duplicated markup -- the "shared code" -- can't practically be 
stored in temporary variables, and secondly can only be factored out 
using METAL, which is a more complicated solution than condition-group.

At its core, condition-group is nothing but a hand-optimization.  As 
Jean-Michel says, it doesn't let you do anything that you can't do now, 
it just lets you avoid lots of redundant tests and copy-pasted blocks of 
markup.  It also lets you annotate related conditions with a 
semi-human-readable name.

Cheers,

Evan @ 4-am