[Petal] [BUG] can't set variables to static values

[Fergal Daly]

On Friday 23 May 2003 11:24, Steve Purkis wrote:
> Yeah - too much complexity in templates is definitely not a good thing. 
>   And I admit that trying to set $lang/fu in this case is a bit of a 
> hack...  But in general, I don't see why auto-vivifying a hash is a bad 
> thing - it's a handy way of grouping things for the template writer.

TAL does't have hashes, so that's why it can't autovivify them. You cannot set 
"a/b". From the TAL spec 

       argument       ::= define_scope [';' define_scope]*
       define_scope   ::= (['local'] | 'global') define_var
       define_var     ::= variable_name expression
       variable_name  ::= Name

variable_name is not a path expression, it is simply a name, there can be no 
"/"s in it.

It really depends on what you're looking for from your templating language. I 
get the impression that TAL is very deliberatley designed to prevent you 
doing anything complicated in the template. That suits me perfectly. Before 
TAL I was using a homegrown system that had variable and loops and that's 
all, everything else had to worked out by the app. I was working with HTML 
coders, some of whom produced lovely looking web page but had quite a bit of 
trouble even with loops and variable substitutions. So I have no desire to 
put any logic at all in my templates.

> But maybe this depends on what you consider to be a presentation 
> issue...  Say for some reason you didn't know how many columns would be 
> in a table until runtime.  I'd like to be able to do something like:
> 
>    $table/cols = foo/number_of_attributes
>    $table/col1/width = 100 / $table/cols
>    ...
> 
> Ok, so it's not the best example in the world :) but IMHO, this is a 
> presentation issue, and should be handled in the template.

Even though you don't like the example, I think it is illustrative. Your ... 
hides a lot. It hides the fact that you would actually need a for loop here 
because you don't know how many columns you will need to initialise. So now 
you have a for loop in your template that doesn't produce any output, you're 
using TAL as a programming language but TAL makes a pretty poor programming 
language as you can see

<div tal:define="table/cols foo/number_of_attributes" tal:omit-tag />
<div tal:for="column table/cols" tal:omit-tag>
	<div tal:define="table/cols/$column/width perl:100 / $table/cols" 
tal:omit-tag />
</div>

apart from being horribly verbose and cumbersome, there's lots more 
functionality missing from TAL the programming language, so rather than 
turning TAL into a very bad programming language you should do all your 
calculating in functions

<table petal:define="table utils/setup_table_widths foo/number_of_attributes">
...
</table>

that way you can use it in all your other templates too.

I know your example was a bad one but I don't think there is an example where 
it isn't easier to just put it in a function and you'll be glad of it if you 
ever have to let someone non-technical near your templates. Just because 
something is a presentation issue doesn't mean the code for it has to be in 
the template. Zope comes with a package of utility functions for table layout 
and other common things and I got the impression that TAL is the way it is 
because it's predecessor (DTML) allowed people to do too much programming in 
the templates and caused a lot headaches,

F