# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.
* `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)`
Regression introduced by the CSS watching code (specifically, f230eba62)
by the sourceIsWatched check. We need to be able to tell the difference
between "source handler didn't do anything because there was an error"
and "source handler didn't do anything because it's web-specific and
this is an os arch".
A simple fix would have been to interpret compileStep.error as
"sourceIsWatched = true", but I didn't think of that until after doing
it the slightly more complicated but more precise way :)
Also, ensure that if the runner rebuilds the client and there's an
error, it properly kills the app process (and the watchers and the
keepalive interval, etc).
Cordova projects often have a different set of files than web targets,
so we would like to be able to target different client architectures in
our bundles. Ideally, we allow the user to use arbitrary client
architectures - but this patch is a step in the right direction by
abstracting out more of the hard coded "browser"/"os" lines.
We accomplish this separation in a backwards compatible way by allowing
api.___ commands to target a "client" architecture. For example,
api.addFiles('a.js', 'client') adds 'a.js' to both the 'client.browser'
and 'client.cordova' targets.
Effects on 0.9 packaging stuff: packages don't have to change, but the
"data.json" file in ".meteor0" has "browser" in some places. We think we
have to fix the troposphere code where this data.json is created.
Some plugins will also be backwards-incompatible with this change, since
many have a "clientArch.matches("browser")" line in the plugin
code. Ideally, we fix plugins so that this stops being an issue, but for
now package authors can just patch that line.
At the compiled (unipackage) level the new names are 'web.browser' and
'web.cordova', replacing 'browser'. In package.js, the new names are
'client.browser' and 'client.cordova', serving as an adjunct to 'client'.
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.
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.
