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

[Steve Purkis]

On Monday, May 26, 2003, at 02:22  am, Fergal Daly wrote:

> 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
>
> [snip]

Ahh, a shame that.  It's not very intuitive from a Perly point of view. 
  And I'm assuming Petal aims to be 100% TAL compliant?

I'd be inclined to implement it anyway, but if no-one else would use it 
then it's not really worth it.  So perhaps Petal::Hash should be 
modified to throw an error if you attempt the above?  At least that 
would save anyone else from falling into the same trap...


> 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.

Yeah, I've also worked with HTML people who don't know the first thing 
about coding.  The way I see it you can either train them up to use 
various template systems if they are so inclined, or you can take the 
HTML and cut it up into templates yourself.  I prefer to work with 
people who can do the former.  And I don't see anything wrong with 
doing complicated things in templates so long as both they and their 
purpose are obvious, but I think it really does boil down to preference.


>> 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>

You don't really need the for-loop for columns of the same width:
	<?var name="set: table/cols foo/number_of_attributes"?>
	<?var name="set: table/colwidth perl:100 / $table/cols"?>

But you're right, the '...' does hide a lot.  it *was* a poor example 
:).

You're right that I am trying to use TAL as a programming language 
(though in a minimalist kind of way).  But that's what I see template 
systems as.  I think the point is that we're coming at this from 
slightly different angles, and there's nothing wrong with that.  You 
prefer to do as little as possible in the templates, whereas I prefer 
to do a little bit more.  But only a little bit, mind you!  I've worked 
on systems where half the application logic was hard-coded into the 
templates...  tell me how you're supposed to debug/test that.. 
*shudders*


> 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.

The major problem I have with doing this is that my HTML guy can't come 
along and change table widths and other presentational things.  Which 
means I have to do it (but heck, I'm doing everything at the moment 
;-).  On projects where the back-end functionality is very complicated 
or labour intensive I like to be able to off-load as much of the 
front-end work as possible.


> 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.

If I do let that happen, there will be a certain amount of trust 
involved.


>  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,

The pendulum swings...  I guess it's a matter of finding a balance that 
works for you.  I prefer tools that don't limit what you can do too 
much - this way you can put your own limitations in place.  And in 
general TAL/Petal lets me do that.  Which is a good thing.

I agree utility functions are a good idea (I've introduced a few in the 
project I'm working on, such as a date string formatting tool).  As an 
aside, I think that that's one place where Petal suffers from an 
out-of-the box point of view - it needs more standard plugins.

-Steve