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

Fergal Daly fergal at esatclear.ie
Wed Aug 6 17:56:38 EDT 2003


On Wednesday 06 August 2003 10:54, Charlie Clark wrote:
> On 2003-08-04 at 12:30:39 [+0200], Fergal Daly wrote:
> > if user.isLoggedIn:
> >   print "You are logged in"
> > elif user.hasCookie:
> >   print "Welcome back please log in"
> > else
> >   print "Please register"

> Au contraire, I think we could live with that because we don't need it
> anyway: we can use dictionary based dispatching for this kind of work. This
> reduces the amount of hard-coded if/elif/else making the code more flexible
> and more easy to maintain.
>
> cases = {isLoggenIn : "You are logged in"}
>
> try:
> 	print cases[isLoggedIn]
> except:
> 	print "You are not logged in"

Dictionaty based dispatch if fine for replacing a switch style if/elif/else 
but once you start doing something besides equality comparisons it's not nice 
or if you want to look at more than one variable you need multilevel 
dictionaries. It also won't work well if the result of the dispatch is more 
dynamic than a fixed string, you need to start passing in context to the 
results of the lookup. Using it in TAL means adding lots of  "structure"s to 
your expressions and keeping chunks of XML in your Python code where the 
designers can't play with them.

> Regarding TALES-extension: I've come to understand and appreciate TALES for
> as an essentially declarative language which is appropriate for
> presentation. Conditions are usually binary in nature and should be kept to
> a minimum in templates for manageability. if/elif/else allows us to build
> chains of procedural logic whereas conditions only execute if met and are,
> thus, essentially purely declarative; it's important to understand this
> distinction, I think.

My point is that people are hand-coding if/else already using define and not. 
It should be easier, can we think of a way to do it?

I'm actually not that botherer about elif, although if that came out as a free 
side-effect I wouldn't complain.

> Re. your actual itch: does it still need scratching? I've read some very
> good suggestions on dealing with the situations where if/elif/else might
> seem to be required.

My itch is that I am going to present TAL to the company I have just joined as 
a replacement for their own home-grown template system which they would like 
to replace. I will be showing them the woderful TAL way to do so many things 
that their system cannot do and I think they will be impressed. But dodgy as 
it is, their current system has if/else and they use it. I'd like to be able 
to present to them the wonderful TAL way of doing that but it's not wonderful 
at all, it involves creating temporary variables and writing 2 tal:condition 
tags and they will say (if not to me then to themselves) "what sort of 
language is this that doesn't have else? Can't be much good, I wonder what 
other surprises are wating for us, let's have a look at Template::Toolkit".

You said summed it up yourself with "I've come to understand and appreciate 
TALES...". TAL is a bit weird and takes a little getting used to. Being 
missing something that everything else has doesn't help to sell it, even if 
there are sometimes (or often or always depending on who you ask) better ways 
to do it. It might be worth having just to lessen the shock for new converts 
or to allow easy conversion of templates from other systems.

So that's my itch and it's not scratched,

F




More information about the ZPT mailing list