Distinguishing HTML vs. text templates

[groue]

There is a need for totally disabling HTML-escaping, and have {{name}} render just as {{{name}}}:

• Turn off htmlentities/htmlencode? mustache#113
• Unescape all values janl/mustache.js#244
• Add option to disable html escape defunkt/pystache#32
• Make escape function configurable bobthecow/mustache.php#86
• Escape query groue/GRMustache#42
• http://librelist.com/browser//mustache/2010/4/16/globally-prevent-escaping/
• Added a noEscape option to Handlebars.compile handlebars-lang/handlebars.js#121
• ...

Currently proposed solutions fall in one of those two buckets:

• RTFM and use triple mustache. This is missing the point, and unfaithful to the "Mustache can be used for HTML, config files, source code - anything." motto of http://mustache.github.com/mustache.5.html (emphasis mine).
• Disable escaping via a flag or a method override. This leads to HTML-safety issues whenever such a template is embedded, via a partial tag for example, into another template that performs HTML-escaping.

After a study of the topic for GRMustache, here is more food for thoughts:

1. The use case "disable HTML-escape" has been turned into a "HTML vs. text" templates at the API level. HTML templates escape their input, text templates do not.
2. Two pragma tags allow to turn a template into a HTML or a text template: {{% CONTENT_TYPE:TEXT }} and {{% CONTENT_TYPE:HTML }}.
3. Pragmas are not the only solution. At the API level, user can programmatically choose the content type of templates at different levels, globally, or per directory, whatever - this is left to the implementor. Pragma tags, if present, must have the last word.
4. When a HTML template embeds (via a partial tag) a text template, the rendering of the text template is HTML-escaped. This basic safety feature is the reason why a "HTML-escape disabling" use case has been turned into "HTML vs. text" concept.
5. The case of users that want to render HTML and disable HTML-escaping is not covered. The bet is that this use case is not common, if not very very rare.

[KosmicTask]

I agree that precise control over rendering would be a general improvement and position Mustache more firmly as a general purpose templating solution rather than an HTML orientated one.

{{{ ... }}} is offered as a solution for preventing escaping. However, in a non HTML scenario the use of the {{{ ... }}} becomes mandatory. For example: A safely templated AppleScript dictionary (aka record in AS) assignment requires:

-- compute myResult
set myResult to { {{{ task-input-variables }}} }

Another issue is that when rendering non HTML content (say AppleScript) a failure to utilise {{{...}}} religiously can result in the somewhat distracting and syntax breaking appearance of one language characteristic (HTML) in the midst of another (AppleScript).

The CONTENT_TYPE proposal seems well positioned. The pragma paradigm is backwards compatible and extensible. The suggested default behaviour seems sensible.

[groue]

For the record, GRMustache 6.2 has shipped with support for text templates (documentation).

[dasilvacontin]

+1

[mytharcher]

+1