I know it's not an elegant solution, but it's a solution and I already use
it: what about tal:define?
It is already possible to fix those tales problems wrapping content within a
tal:omit-tag-ed "definer element" or directly a tal:define block. Otherwise
we can set a tal:define also inside the same tag as it should be evaled
before other attributes.
I'm probably loosing the point of the discussion, but I don't really see any
reason to make the syntax more complex and also a bit heavyer to compute for
the parser...
Your patch proposal could be as useful as compromising, as it could make
PHPTAL more complex than it should be... Don't you think so? :-)

2009/11/17 Kornel Lesiński <kor...@aardvarkmedia.co.uk>

> 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

Marco Pivetta - Ocramius Aethril
Standard Ogame Project - StOgame
Making Ogame a better place...
Sent from Padova, Veneto, Italia
PHPTAL mailing list

Reply via email to