[stringtemplate-interest] Formatting vs. Escaping in an AttributeRenderer

[Tobias Güntner]

Am 10.09.2011 18:12, schrieb Sam Barnett-Cormack:
> I suggested an orthogonal 'filter' API (as in separate from adapters
> and renderers) a while back,

In the "Group Syntax extension for ModelAdapter and Renderer" thread 
from July? That's the only reference I found.

> that would take what came out of adapters and renderers and 'filter'
> them in some way. There's lots of ways it could work in terms of
> default, non-default, when to apply which, etc etc.

Yes, a general "filter" option would work. I think a clear 
adapter->render->filter/escape/postprocessing pipeline would definitely 
be nice to have. I would prefer a more concise syntax, however, because 
escaping is needed more often than formatting (at least in my experience).

Since we're talking about language extensions anyway, let my mind wander 
for a while. Other features could be useful, especially with escaping in 
mind.

For example, an easy way to specify escape sequences. It would be nice 
if I could just write something like

xml-attribute:
     [\r\n\t ] -> copy      // copy character as-is
     [\0-\x1f] -> invalid   // throw exception
     '&' -> "&"         // replace character as requested
     '<' -> "&lt;"
     '\"' -> "&quot;"
     ...

and have ST automatically generate the appropriate code.

Some sort of error checking would be useful as well. Perhaps typesafe 
templates are a little farfetched, but at least ST would complain when I 
embed unescaped JS in HTML.

For example, we could associate a type with every template. Templates of 
the same type can be combined freely, but different types require 
explicit conversion. Then, for every type, we could define several 
escape operations which transform plaintext into something usable in 
this context (like a type cast for strings). Perhaps a few examples will 
explain it (syntax is made up, but I think you'll get my point):

// default template type/context is "plaintext" (or null?)
// Attributes (or more precisely the output of an
// AttributeRenderer) have type "plaintext" as well.
greeting() ::= "\"Hello\",&nbsp;World!"

// context/return type is "js"
// escape greeting() for use as string literal (this also
// changes the type from "plaintext" to "js" in this case)
alert() -> js ::= "alert(\"$lit!greeting()$\")"

// escape alert() for use as attribute content
link() -> html ::= "<a href=\"...\" onclick=\"$attr!alert()$\">...</a>"

// OK: Use in "plaintext" context is always allowed to
// ensure backwards compatibility (no escaping done).
// (Perhaps the return type could be inferred automatically?)
test1() ::= "<p>$link()$</p>"

// Error: Cannot use greeting() (type "plaintext") in "html" context
// (Unless a default escape mode was specified for this context.)
test2() -> html ::= "<p>$greeting()$</p>"

// OK: Escape to use as element text content
test3() -> html ::= "<p>$cdata!greeting()$</p>"

// OK: I really mean it! Do not escape!
test4() -> html ::= "<p>$html!greeting()$</p>"

// Error: Cannot use alert() (type "js") in "html" context
test5() -> html ::= "<p onclick=\"$alert()$\">...</p>"

// OK: link() (type "html") can be embedded in other "html" template
test6() -> html ::= "<p>$link()$</p>"

// OK: Print the source code
test7() -> html ::= "<pre>$cdata!link()$</pre>"

// Error: "lit" escape mode is only valid in "js" context
test8() -> html ::= "<p>$lit!greeting()$</p>"

// OK: First escape as js string literal, then as url path,
// finally as attribute content for use in "html" context
test9() -> html ::= "<a 
href=\"javascript:$attr!url!lit!greeting()$\">...</a>"

// OK: Mistake not detected, but impact is limited
test10() -> html ::= "<p $link()$ >...</p>"

A template writer would still need to choose the correct escape 
function, but at least ST could detect one of the most dangerous 
mistakes, i.e., if no escaping is done at all.

Back to reality ...

> I still think it's a good idea, but there wasn't a lot of enthusiasm
> for it ;)

So ... When is it done? ;)

Regards,
Tobias