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

[Fergal Daly]

On Wednesday 28 May 2003 11:47 am, Steve Purkis wrote:
> On Monday, May 26, 2003, at 02:22  am, Fergal Daly wrote:
> 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 don't think so. There are already some things you can with Petal that you 
can't do with TAL so one more wouldn't be out of the question.

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

There certainly should be an error at least.

If you are going to implement it, here's something else to think about.

path:a/b can mean $hash->{'a'}->b() or $hash->{'a'}->{'b'} depending on 
whether a is an object or a hash. Also path:a/0 can mean a hash or an array 
dereference. This gives rise to the question of what to autovifvify if you 
try to set a/0, a hash or an array? Most likely an array I suppose.

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

There is a crucial difference between Petal and TAL, at the moment Petal 
doesn't do local variables whereas TAL does them by default, so in TAL you 
can do

<table tal:define="cols foo/number_of_attributes;colwidth 
perl:100/$table/cols">
...
</table>

you don't have to worry about overwriting the old value of cols and colwidth 
because once you get to the </table>, the old values will come back. But like 
I said, TAL doesn't do that yet.

> 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 want as little as possible in the templates, I guess we just differ on our 
wants.

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

Yeah. TAL is just a small piece of Zope. Petal stands alone and so is missing 
all the standard utilites that come with Zope. I guess someone should look at 
what utilities Zope provides for templates and produce something similar... 
but not me.

F