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

[Steve Purkis]

On Wednesday, May 28, 2003, at 10:18  pm, Fergal Daly wrote:

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

Agreed - I think that would be the best place to start.


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

Yeah, and you wouldn't really want to set the method of an object 
either.  All things that need to be taken into consideration.

This is why I'd split things off into an expression parser.  Half of 
this work is already done in Petal::Hash::Var - it finds the variable 
you want to set.  Deciding how/what to set it (array/hash/error) is the 
only new thing.


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

You mean Petal doesn't do that yet, right?

That's a good point.  I automatically assumed variables were scoped 
like that, just because it made sense to me (maybe it's an assumption I 
carry forward from XSLT?).  I've actually been using the 'ugly' syntax 
to set global variables, because there's no easy way to define their 
scope (unless you're in an if-block, or similar).


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

Sounds like a good plan, but unfortunately I don't have time to work on 
it either..

-Steve