To maintain proper bc I would suggest another namespace, like ntales (new tales)

The problem of modifier scope is difficult, unless you can introduce
syntax like this:

(php:foo()) + foo/bar

Braces around the modifier code would define the scope, but this is
still error prone if you decide to have something like php:foo('(hi')
in which the brace count would screw up unless you do tokenizing.

To be honest, to solve the <option> problem I just add a selected
attribute in my option list and add "selected exists: row/selected"
which works fine, no need to pass two variables into phptal.


On 11/17/09, Kornel Lesiński <kor...@aardvarkmedia.co.uk> wrote:
>
> There are few cases where simple TALES (expressions like "foo/bar/baz")
> isn't working well, most often comparison of selected <option>, PHPTAL's
> pythonified/xmlized PHP syntax has gotchas and it's confusing to jump
> between the two.
>
> I think in that case best solution would be to make TALES more powerful,
> but I wonder how much powerful? Should I add math expressions? String
> concatenation? Should I allow passing of function arguments? What the
> syntax should be like?
>
>> foo/bar EQ baz/quz
>
>> foo/bar + baz/quz
>
> Should modifiers work inside TALES?
>
> How do you mark end of modifier's content?
>
>> foo/bar + php:foo()
>
>> php:foo() + bar/baz
>
> http://phptal.org/wiki/doku.php/improvedtales
>
>
> --
> 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