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

[Fergal Daly]

On Friday 01 August 2003 14:26, Evan Simpson wrote:
> 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 :-)

As I've pointed out, people are already working around the lack of if/else in 
a fairly ugly way. Isn't controlled, standardised, safe ugliness better than 
what currently exists?

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

What can you split on? " " is a valid character in a path name and pretty much 
anything is a valid character in a python expression. You can't split it 
until you know what it is and you don't know what it is until you've parsed 
it.

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

Yes, sorry, I didn't get that part.

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

My internal jury is still out on condition-group, it can do more than 
if/elsif/else but it seems to me that when you use it to do more it gets very 
hard to follow (see above for an example of me not following ;-)

F