strict mode

[schuyler1d]

right now templates can include raw javascript. There should be a mode (if not the default) which only allows variables, calls, and (in)equality expressions.
i.e. this should be IMPOSSIBLE:
{{= (get_Val() ? 3*4/this : window.location='http://github.com/jquery/' }}
This kind of strict approach is essential if the implementation can be written cross-language, and force the separation of template and code.

This issue was brought up in the original announcement:
http://forum.jquery.com/topic/templating-syntax#14737000000824492
where the author gives an example of a way to implement this:
http://github.com/borgar/hugs/blob/master/hugs.js#L167

[glebm]

I believe nested data access should be permitted as well, e.g.: a.b.c, but not a.b().c.

[BorisMoore]

See also https://github.com/jquery/jquery-tmpl/issues#issue/66:
Better error handling options

[mikesamuel]

In the draft spec, http://wiki.jqueryui.com/w/page/37898666/Template , if you wish to restrict substitutions you can implement a verifier pass that rejects any "=" node that has content that does not fall in some subset of member expressions. See plugin compiler passes in section 9.

Be aware though that you cannot rely on control not escaping just because there is no explicit function call. Implicit valueOf, toString can cause control to escape, (new Image).src="javascript:...", and getters/setters can all cause non-obvious side-effects.

[schuyler1d]

what are the possibilities of including a verifier in core? As default?
I can write the verifier, if a patch would be accepted.

[rdworth]

Thanks for taking the time to submit this issue. Just wanted to let you know this plugin is no longer being actively developed or maintained by the jQuery team. See README for more info.

[schuyler1d]

thanks. It was a good goal--jquery would have benefited from a single templating engine--but there seems to be contradicting usecases in JS world to truly consolidate. Long live handlebars.js?

[rdworth]

jQuery can still have and benefit from a single template engine, it will just be maintained by the jQuery UI team. The previous version wasn't developed with them as stakeholders and so had different design goals. For this reason, the design and development was started afresh, rather than continuing in this project.

Surely there will always be plenty of choices when it comes to templating engines. jQuery UI will provide an interface that will support using your own favorite template engine, but will only fully support the one it ships. This is an example of a goal that wasn't initially part of the jquery-tmpl project.

[BorisMoore]

For the codeless (strict) approach, see also the ongoing work on JsRender. Take a look at this post for more context.