HI Jim It's a good point you raise. I personally don't consider tal: and metal: tags to really be a traditional programming language, more a way of including directives and/or python into an XML/html namespace. I think it would depend if you consider each tal: statement in a tag to be all part of a single statement. I view it as being a number of seperate attributes in a xml/html tag, and attributes within a tag are typically order independant. ie <img src="file.gif" border="0" vspace="1" hspace="1"> or <img border="0" vspace="1" hspace="1" src="file.gif"> render exactly the same thing. In addition event handlers in html ie onClick onBlur etc are all order independant. now adding tal: attributes that where order dependant would seem to fly in the face of that convention. (Admittedely there are probably no strange dependancies that could be introduced with different orders of border, src etc) It would also be potentially dangerous have specific authored ordering when non programmers start editing page templates, and accidentally change the order of tags because they looked nice in a different order, or when someone uses a graphical html editor, I have seen ones, where you are given a nice dialog box to edit attributes of a tag, and when it write the values back it always writes them in "it's internally specified order" not the order you specify. This I would imagine could introduce all sorts of nasty bugs. On the basis of in place ordering would it also mean that a attribute should be declared before a tal:attributes could be used. Within an attribute ie tal:define the statements are executed in the order they are specified, which does make sense. I suppose I have put forward more than 2c now ;-) T On Fri, 2002-05-10 at 09:30, Jim Penny wrote:
On Fri, May 10, 2002 at 09:07:26AM +0800, Tim Hoffman wrote:
Hi
Just my 2c worth, but I would like to defend order of execution of ZPT. What it does mean for me is I can guaruntee zpt commands will "always" be processed in a known order irrespective of where you put them in a tag, this I like ;-)
Would you defend a python interpreter that always moved definitions ahead of conditionals ahead of loops?
Does even a "intentionally limited templating language" have the right to second-guess the programmer and re-arrange the order of written commands?
Yes, I am aware that 'C' and fortran and many other languages may do rearrangement of arithmetic expression, and that this may be side-effectful. But, can you point me to any other language that reorders looping and conditionals?
Jim
What I do miss is "else" clause but I think it would be probably be too hard to implement, and too much of encouragement for people to start putting more logic in the template, so on the whole it is probably best to leave it out.
See ya