[ZPT] If/else?

Chris Withers chrisw@nipltd.com
Fri, 11 May 2001 10:46:36 +0100


Guido van Rossum wrote:
> 
> > Guido van Rossum wrote:
> > > Our latest proposal will remove these again, and add a
> > > simpler mechanism instead: "x | y | z" will evaluate to the path x if
> > > it is defined and non-empty, otherwise to y if it is defined and
> > > non-empty, otherwise to z (which must be defined, but may be empty).
> >   ^^^^^^^^^
> >   should that be just 'empty'?
> 
> No, y must also be defined and non-empty in order to qualify.  You can
> do x|y|z|a|b|c and it tries each of them in turn until it finds one
> that exists and is non-empty -- except the last one may be empty
> because there's no alternative, but it must still be defined.

Ah, okay, I understand now :-)

> > Yeah, I'd agree with that, but it shouldn't do a blanket exception
> > catch either, like dtml-if used to ;-)
> 
> You better tell that to Evan and Jim!  It looks like we should spell
> out exactly which exceptional conditions are equivalent to "false"
> here and which ones aren't!  (There's always on-error for catching
> more severe errors.)

I really don't think any exceptions should be caught.
If y can raise a valid exception that means 'evaluate as false', then y should
catch that exception and return false.
Any kind of 'ah, that exception meant that that isn't found which is okay' on
the part of ZPT is second guessing what might be a bug in the code and tracking
those down has been painful for me in the past...

> > > For those cases where the |-separated sequence doesn't have enough
> > > expressive power, we propose to fall back on Python expressions
> > > ("python:<expression>") which are all-powerful,
> >
> > Are these in there already? I hope not, if fact, please god no!!! :-(
> 
> Yes, they have been part of the TALES design and implementation from
> the start.  What's wrong with them?

Well, ZPT's used to be called Presentation Templates, which I liked because it
showed exactly where they fitted in the Presentation-Logic-Storage model.

Add the ability to write raw python in them means that people slide down the
slippery slope to have oodles of logic intertwined with your presentation stuff.
People then complain that ZPT, like DTML, results in reams of unreadable code
written in two (three?) languages intermixed on the same page.

Furthermore, they end up asking for more language constructs and the ZPT authors
end up having to implement the equivalents of <dtml-if> <dtml-try> <dtml-raise>
<dtml-let> ...etc...

As a metaphor, if you don't want kids to shoot each other, don't let them take
guns to school ;-)

Right, that's why I don't want them, but, to be honest, having them there
doesn't mean I have to use them so if it causes too much controversy I'll just
shut up and enjoy using the good features of ZPT and leave python expressions
alone (and beat anyone here at NIP over the head with a large stick if they use
them ;-)...


> > 'expr=' was the beginning of the end for DTML and python directly in
> > ZPT is metaphorically equivalent, for me, to allowing {} as a block
> > delimiter in python
> > ;-)
> 
> Please give a less emotional explanation.

Heh, can you tell I've been bitten hard by this in the past? :-S

cheers,

Chris