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

[Steve Purkis]

Hi Fergal,

On Friday, May 23, 2003, at 12:40  am, Fergal Daly wrote:

> On Thursday 22 May 2003 15:56, Steve Purkis wrote:
>> Yup - auto-vivifying a hash was what I was hoping it would do...
>
> As far as I know, Petal (and TAL) only set variables at the top level. 
> So
> trying to set $lang/fu is not supposed to work. I think this makes 
> sense as
> it discourages peple from building too much complexity into their 
> templates.
> They're pretty much designed to be used as shortcuts so you don't have 
> to
> keep typing $big/long/variable/path/expression.

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.

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.


>> These are the possible solutions I've thought of:
>> 1. Use single values for lang attributes (ie: $lang_name vs 
>> $lang/name)
>> 2. Create a 'fake' value for lang in the template.
>> 3. Change Petal so that it returns false instead of throwing an error.
>> 4. Move this logic into the back-end.
>>
>> I'm doing (1) at the moment, and was investigating (2).  (3) has
>> occurred to me in the past, but seems like it might be too much work.
>> And I'd rather not do (4) because this is a presentation issue and
>> should be handled in the presentation layer.
>
> I think (4) is actually the correct option. Even if language was a
> presentation issue, setting all the variables is not presentation and 
> also
> it's messy enough that you don't want to have to think about it and in 
> your
> template code.
>
> That said, I don't think language is a presentation issue, at least 
> not in the
> same way style and layout are.

In the above example, use of 'lang' _is_ a presentation issue - but in 
all fairness, I think I may have chosen a misleading example :).  
Languages are just one type of business object that a user can edit.  
Perhaps 'car' would have been a better example than 'lang'.

After sleeping on it, I think (3) is actually the best option.  It also 
fits in line with other templating systems I've used - if a value for 
the variable cannot be found, return undef, false, or something along 
those lines.  But for backwards compatibility, I think a switch in 
Petal would do the trick ($Petal::ERROR_ON_UNDEF_VAR ?).


>  If you are making something multi-language you
> really have three layers
>
> a: backend logic
> b: localisation
> c: presentation
>
> a: decides what you want to say and produces data, b: checks that data 
> for
> anything that needs to be localised to the desired language and c: 
> then takes
> the localised strings and data and presents them in the correct layout 
> and
> style. In reality a and b are usually merged together because it's 
> usually
> easier to localise strings when they are generated than go hunting for 
> them
> afterwards. Separating all 3 layers would only be useful if you wanted 
> to
> present the same data in several different languages but just generate 
> it
> once,

I'm actually trying to do all of my localization in the presentation 
layer.  At the moment, I'm using flags for messages that need to be 
localized (such as 'user removed', 'user modified', 'user name 
invalid', etc.).  I realize this is a simplistic approach which won't 
work with complicated messages, but I'm hoping that if I tread 
carefully I'll be able to avoid generating complicated messages and use 
this across the board.  *fingers crossed* :)

If things get hairy, I plan to bite the bullet and fall back to 
Locale::Gettext or Locale::Maketext.

Thanks for writing,
-Steve