I vote for not changing the current behaviour; I agree that if it's
documented, it can be a little weird ;-)

Personally I would choose to have a money formatter TALES construct,
because I hate having to go through my templates again when I start
adding another currency for instance.


Best,
  Tjerk

2009/10/27 Kornel Lesiński <kor...@aardvarkmedia.co.uk>:
> On 27-10-2009 at 12:34:42 Iván Montes <drsl...@pollinimini.net> wrote:
>
>> I vote for not changing the behavior but I would like, for next major
>> version of PHPTAL, to break BC for escaping and remove the escaping of
>> the dollar symbol:
>>
>> ${variable} -> variable
>> $${variable} -> $variable
>>
>> Since TAL is heavily based on HTML/XML semantics I guess it makes more
>> sense to escape using unicode point codes (&#36; for $) or custom
>> entities.
>
> Unfortunately in XML it shouldn't matter whether you use literal $ or &#36;
> (the difference is completely lost if you use W3C DOM for example).
> Theoretically PHPTAL should support &#x24;&#x7b;var&#x7d; as well as ${var}
> :/
>
> Custom entities require custom DOCTYPE/DTD, and that's just a can of worms.
>
>
>> This would remove the need for backtracking when parsing
>> interpolatable texts and remove possible ambiguities like the one
>> described in the original mail.
>
> It can be unambiguous. It just has to be clearly defined and implemented in
> one way or another :)
>
> --
> regards, Kornel
>
> _______________________________________________
> PHPTAL mailing list
> PHPTAL@lists.motion-twin.com
> http://lists.motion-twin.com/mailman/listinfo/phptal
>



-- 
--
Tjerk

_______________________________________________
PHPTAL mailing list
PHPTAL@lists.motion-twin.com
http://lists.motion-twin.com/mailman/listinfo/phptal

Reply via email to