Now any plugin can request that its files be treated as "templates" by
setting an isTemplate flag.
(This API is just as supported as you'd expect based on the fact that
you still can't access it without calling a function which starts with
"_transitional_".)
Tested by renaming leaderboard.js to a.js and confirming that it still
works (and that it *doesn't* if templating does not set isTemplate).
Trying to include them later with {{> content}}
fails. We could disallow the other built-ins,
eg 'if' and 'elseContent' but sounds less likely
that users will try to define templates with
those names, and this simple change lets us
not duplicate code.
- Get rid of DomRange "host objects" (too confusing)
- start to use `r instanceof DomRange` instead of `'dom' in r`
Ported domrange tests; all tests pass
Now Spacebars syntax errors (as well as html_scanner errors) go through proper error reporting channels rather than throwing exceptions. For simple cases, we are back to showing nice errors like Handlebars did on devel, with context.
Next: Comb the spacebars compiler for errors that are thrown or lack good line numbers. Go through our own list of bad error messages.
This commit does the minimum to switch to the new renderer,
by mapping .html to html2_scanner. Now we have to remove
all the references to "2" and all the old dead code, of course.
Our use of emboxValue breaks test-in-browser pretty severely
by assuming that in `{{#each results}}`, if `results` is `===`
to what it was last time, then there is no change. In fact,
test-in-browser mutates arrays and expects invalidating the
result to cause a re-render.
Note that this is only triggered when coffeescript manages to output invalid JS,
which should be unlikely.
This does remove the feature where lines and columns were suppressed for parse
errors in the output of template compilation. but (a) that shouldn't happen,
and (b) we'll fix this by implementing source maps for spacebars.
@export is now an error in test slices.
This is preparation for ensuring that any slice with exports has at least
"Package.foo = {}"; without this commit, both the use and test slice would (with
that change) try to overwrite Package.foo.
Remove the attempt to allow @export in 'use strict' CoffeeScript files:
ECMAScript 'use strict' is fundamentally incompatible with our implementation of
exports, and it was probably a bug that this used to work at all.
