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
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
> regards, Kornel
> PHPTAL mailing list
Marco Pivetta - Ocramius Aethril
Standard Ogame Project - StOgame
Making Ogame a better place...
Sent from Padova, Veneto, Italia
PHPTAL mailing list