* `Template.__create__` is now `new Template`
* `Template = Blaze.Template`
* `Template` is a constructor function
* `Template.foo instanceof Template` (but keep `Blaze.isTemplate`)
* No more `Blaze.runTemplate` (use `template.constructView`)
* `constructView` instead of `__makeView`
* template objects have `__kind` and `__render`
* No `__viewName`, `__templateName`
* `Template.__body__` is now `Template._body_` (and renamed methods)
* No `Template.__lookup__`, instead `(name in Template) && (Template[name] instance of Template)`
* `Template.__define__` replaced by `Template.__assign(name, template)`
You put it in the body of your app and put a helper on UI.body2. Bam.
For now, the modifications to CodeGen will go in CodeGen2. Otherwise, the server-side "webapp" template would barf.
Gotta make more template tags work now.
The pattern of one package defining Spacebars and another augmenting it with methods like Spacebars.parse is too confusing.
The symbols `parse`, `compile`, `TemplateTag` are now on `SpacebarsCompiler`. You can now access `SpacebarsCompiler.optimize`, and we can start exposing more symbols.
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.
@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.
