Community
Participate
Working Groups
The FOR loop should support a separator expression that is executed in between two loop runs. A pre and post expression your also be nice. These should only be executed if the for loop runs at all. The Xpand syntax might be a bit noisy, maybe we can find something nicer.
The semantics of the separator are somewhat unclear. Consider the following template: <<FOR a: iterable SEPARATOR ','>> <<a>> <<ENDFOR>> That is the trailing linebreak after the <<a>> is part of the for loop body. However, I would expect the result to be something like a1, a2, a3 instead of a1 ,a2 ,a3 We could either implement a more complicated algorithm for separators and before / after or rely on the assumption that SEPARATORs will usually be used in singleline for loops like <<FOR a: iterable SEPARATOR ', '>><<a>><<ENDFOR>> which will result in a1, a2, a3
(In reply to comment #1) > Static template text <<FOR a: iterable SEPARATOR ','>> > <<a>> > <<ENDFOR>> It is even worse, the leading line break before the <<a>> is part of the template body, too. The result would actually look like this: Static template text a1 , a2 , a3 So there may be a need to implement something more complicated for loops in rich strings.
That's a pity. I think the second situation boils down to a general problem with the whitespace handling. That is you typically introduce those line breaks in order to split template line into two lines for readability which in the output should be one line. This happens quite often, because the extra template logic makes lines longer. Maybe we need something to suppress line breaks explicitly? Something like: > Static template text <<FOR a: iterable SEPARATOR ','->> > <<a>> <<->> > <<ENDFOR>> (note the hyphen) comes to mind :-)
What I've implemented so far is ''' «FOR i: 1..3 SEPARATOR ','» «i» «ENDFOR» ''' -> 1, 2, 3 I think we should give this one a try and see how it works in practice. What do you think?
+1
pushed to master.
Closing all bugs that were set to RESOLVED before Neon.0