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

[Daniël Hooymans]

Hi,

Interesting discussion. I'm still rather new with Zope and ZPT (I still do not have the time and oppertunity to dig deeper into Zope). But while reading the subject something comes into mind.

In the discussion, some refer to use TAL/METAL in a programming way. Containing repeat/case/if constucts. But this isn't correct in my opinion. Purpose of TAL was to make it possible to seperate programming and design. Some tend to forget. 

I see TAL only as a template for my content. Where does which type of content go? That's what IMHO TAL is all about. And if one looks to ZPT this way no if/else construct has to be available. Though i do understand some would like having this construct.

Greets,
Daniel


> -----Original Message-----
> From: Fergal Daly [mailto:fergal at esatclear.ie]
> Sent: maandag 4 augustus 2003 12:31
> To: Chris Withers
> Cc: zpt at zope.org; Jean-Michel Hiver
> Subject: Re: [ZPT] Re: TAL's lack of an else...
> 
> 
> On Saturday 02 August 2003 10:51, Chris Withers wrote:
> > Fergal Daly wrote:
> > > Yep, but that's programming in XML for you. Anyway, the 
> alternative if
> > > even worse
> >
> > I don't agree ;-)
> 
> I presume you are not claiming that programming in XML is progress...
> 
> > > <tal:x tal:define="temp_cond_var user/isLoggedIn">
> > >   <tal:x tal:condition="temp_cond_var">
> > >     welcome
> > >   </tal:x>
> > >   <tal:x tal:condition="not:temp_cond_var">
> > >     please login
> > >   </tal:x>
> > > </tal:x>
> >
> > This contains the same level of complexity as the 
> tal:condition-group stuff
> > you and Evan are proposing, but doesn't require knowledge 
> of more syntax.
> 
> I am not propose anything with Evan. The first time I read 
> the condition group 
> stuff I didn't get it. Now I get it and I can see some uses 
> for it but I 
> think it's much too easy to make a mistake with it.
> 
> What I was proposing was a way to do if/elsif/else, no more 
> no less. I am 
> quite surprised to see people defending TAL's lack of else. 
> Would you be 
> happy with Python if instead of
> 
> if user.isLoggedIn:
>   print "You are logged in"
> elif user.hasCookie:
>   print "Welcome back please log in"
> else
>   print "Please register"
> 
> you had to write
> 
> isLoggedIn = user.isLoggedIn
> if isLoggedIn:
>   print "You are logged in"
> if not isLoggedIn:
>   hasCookie = user.hasCookie
>   if hasCookie:
>     print "Welcome back please log in"
>   if not hasCookie:
>     print "Please register"
> 
> I doubt you would be happy with that. So why are people happy 
> with it in TAL? 
> It would be undestandable if it was an uncommon construct but 
> it's not, it's 
> very common and the whole purpose of a good language is to 
> make the very 
> common as easy as possible.
> 
> Some other comments:
> 
> > Stuff used in this context should _never_ have side effects!
> > If it does, you deserve the complexity you get!
> 
> Whether due to side effects or expense, the most common 
> practice seems to use 
> a temporary variable so template authors must be worried 
> about something.
> 
> > That said, Cache Managers are suc ha doddle to use in Zope, 
> I think Jean's 
> > suggestion is fine.
> 
> I'm not familiar with them but I would guess wrapping all of 
> your objects in 
> cache managers so that they can be used safely in your 
> templates is not a 
> good idea.
> 
> > And end up with Perl 7.XML? No thanks....
> 
> Perhaps we should deprecate use of named variables and 
> tal:condition and start 
> using registers, branch-if and gotos?
> 
> F
> 
> 
> _______________________________________________
> ZPT mailing list
> ZPT at zope.org
> http://mail.zope.org/mailman/listinfo/zpt
>