[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