[stringtemplate-interest] Formatting vs. Escaping in an AttributeRenderer
Tobias Güntner
fatbull at web.de
Sat Sep 10 07:36:24 PDT 2011
Hello!
I am new to StringTemplate and I am experimenting with string escaping.
The first advice I found was to register a custom attribute renderer and
specify the escape mechanism in the "format" option. This works fine for
the most part, but it has a few drawbacks:
* It interferes with "normal" renderer usage, i.e., I can either escape
or format, but not both. To overcome this limitation, I would have to
parse the format option and delegate calls to a second renderer which
does the real formatting - for each type in a STGroup. Certainly doable,
but it feels like a clumsy workaround.
* I have to remember to specify the correct format everywhere. I find
this tedious and error-prone. So I figured I could instead escape by
default and say format="do-not-escape-this-time" if I want something
else. This did not work, however:
public class Test {
private static class EscapeRenderer implements AttributeRenderer {
public String toString(Object o, String format, Locale locale) {
return '[' + String.valueOf(o) + ']';
}
}
public static void main(String[] args) {
STGroup g = new STGroup('$', '$');
ST st = new ST(g, "start$test;separator=\"sep\"$end");
st.add("test", "aaa").add("test", "bbb").add("test", "ccc");
g.registerRenderer(Object.class, new EscapeRenderer());
System.out.println(st.render());
}
}
The result (using version 4.0.4) was:
[start][aaa]sep[bbb]sep[ccc][end]
For some reason, literals are escaped as well. Shouldn't this print
start[aaa]sep[bbb]sep[ccc]end
instead?
* I realize escaping and formatting are mostly orthogonal concepts.
Formatting converts arbitrary objects into strings depending on the
needs of the user, whereas escaping transforms strings depending on the
context of the output. I suppose using an AttributeRenderer to escape
strings is probably the wrong approach altogether.
Another advice I found was to automatically add properly escaped strings
whenever new attributes are added to a string template. I do not like
this either:
* The caller has to know exactly how a certain value is going to be used
in the template. This dependency can be avoided if every attribute is
escaped in every possible way, but that would probably be a waste of CPU
and memory most of the time.
* Recursive escapes (e.g., an HTML fragment in a JS string literal in an
HTML attribute) are cumbersome.
* Escaping is done before formatting. It should be done last, just
before the output is concatenated.
A custom model adapter could be used to escape attributes on demand
(i.e., whenever a magic property name is read), but that does not solve
the other problems.
Are there other/better ways to escape strings in ST?
Regards,
Tobias
More information about the stringtemplate-interest
mailing list