[stringtemplate-interest] maps, length, wrapping

[Kay Roepke]

On 29. Jan 2006, at 3:40 Uhr, Kay Roepke wrote:

> Could we possibly use some option like separator to do that?
> E.g.:
>
> <names:{<it>}; separator=",", maxLineLength="80", lineSeparator="\\ 
> \n">
>
> with the appropriate warning when the first element is already  
> longer than maxCharLength?
>
> Then we wouldn't even need any comparisons (which probably would  
> spark discussion about being able
> to test for attribute values later down the road...)?
>
> Is this complete crap, or does it sound sensible?


Happily talking to myself...

Just for the sake of it, I just tried an adhoc implementation of the  
foresaid.
Adding the options to action.g was pretty easy but the implementation  
in ASTExpr.java's write method
is a bit awkward.
Basically the problem is that write calls itself recursively and just  
returns the total number of characters
written to the output stream. The thing is that we have to know  
beforehand just how long that chunk is gonna be
to insert the appropriate lineSeparator before the line is exceeding  
the maxLineLength. Then we'd have to write
out the lineSeparator and write the actual line in the next pass  
through write.
But that would mean returning the characters to be written, too.  
Additionally we would have to take the lineSeparators
length into account, too, so we don't spill over the limit the  
template writer set just by putting out the separator
itself.

So...the way I see it, the best solution for this would be to  
separate the actual writing out into a "inner write()" and
call that one from the current write() (which then could still return  
the length of the characters written). It would
simply change to take the additional options lineSeparator and  
maxLineLength.
However, before I do that major surgery on your code, Ter, I'd like  
some feedback ;) I don't want to ruin your source code...

Oh yeah, there are two additional problems :(
1) If the thing to be written is not something iterable (something  
which gets written using the AttributeRenderer or directly via
calling .toString() on it) we can't put the lineSeparator in. Just  
the warning about exceeding the permitted line length...
2) If the item separator contains newline characters, we do all the  
checking and will be putting in the lineSeparator in
inappropriate places, because we don't see the newlines. In other  
words, we just count all the characters written and assume
we are still on the same line, even if we aren't. Bummer. Of course  
one could argue that this is somehow the fault of the template
author, but things could get nasty if the separator itself comes from  
a template. Easy to overlook. Hardcoding the check for
newlines seems hackish to me.

Wow, lot of stuff for a simple feature.

Any ideas/rants/trolling? ;)

Kay