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 ;-)
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
> 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?
> > 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
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -