On Fri, 25 Mar 2011 07:34:51 -0000, Anton Andriyevskyy <x.meg...@gmail.com> wrote:

Great feedback!

*1. IF-THEN-ELSE*.

That's a tough one. I see two issues:

1. I can't figure out XML-friendly syntax that works well for if/else and especially if/else-if/else 2. There's beauty in TAL's purely functional design: elements are independent, state doesn't escape tree structure (except few edge cases I like to pretend don't exist :), and it can be generated in one pass (with no look-aheads).

e.g.:

<x tal:if="cond">…</x>
<y tal:else="">...</y>

would require keeping result of 'if' until 'else' is found, and result of 'if' would escape its element. Also, probably any content between if and else would have to be forbidden (or would give unexpected result?)

This:

<x tal:if="cond">
        <y tal:else="">...</y>
</x>

creates weird situation where all of <x> is discarded, *except* <y>, and nesting of elements is different than what you get after execution (e.g. you might want if/else versions of <script>, but HTML editors [with syntax highlighting, etc.] will get confused when you put <script> in <script>).

So a more TAL and XML-friendly version would be:

<tal:block tal:if="cond">
        <x tal:then=""/>
        <y tal:else=""/>
</tal:block>

and this basically is in TAL already:

<tal:block tal:define="c cond">
        <x tal:condition="c" />
        <y tal:condition="not:c" />
</tal:block>

*2. Calling standard php functions*

After 7 years of making websites, I get convinced that using simple php
functions does not necessarily mean moving business logic into template.

F3's "Template Expressions and Functions" section has very useful and simply controlled way to allow / disable native function calls.

I think TAL should be more powerful, but not everyone agrees where to draw the line. See previous discussions around
http://phptal.org/wiki/doku.php/improvedtales


<span tal:content="php: number_format(a/b/c, 2)" />

The problem #1 here is that syntax becomes ugly when I want to still call
a/b/c but I cannot do so because I'm inside PHP modifier.

It's because PHP uses '/' for division. Sooner or later someone would try to display e.g. average amount:

tal:content="number_format(sum/number_of_items, 2)

and get pretty confusing error message about integer not having number_of_items field.

I'd rather not add another case where spaces around operator are meaningful (they already are for '.').

It could work if prefix was required, e.g. path:a/b/c, but even then there's still some ambiguity:

php:foo . string:bar . baz

Is the string 'bar' or 'bar . baz'?


I think it would be best if we could come up with nice and powerful TALES syntax, and obsolete the php: prefix.


<tr class="{(@key+1)%2?'odd':'even'}">

<tr class="${php:(key+1)%2? 'odd' : 'even'}">

I think both could be better (a combination of '% ? :' is not very friendly), e.g.

<tr class="${odd-class:key}">

...or just drop support for old IE and use :nth-child(2n) CSS selector ;)


*3. Combining attributes*

It's often useful to combine attributes. Example:

<div class="wrapper" tal:attributes="class wrapperExtendedClass | nothing " />

Is there a way to ADD more class values instead of replace them?

addattributes doesn't seem to be flexible enough. You might want to prefix/wrap/modify value. Perhaps tal:attributes="class this/class . ' blah'"?

You can also do:

<div class="wrapper ${wrapper2 | nothing}">

if you're not too fussy about extra space it generates.


--
regards, Kornel Lesiński

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

Reply via email to