with back-compat.
The “old-style” syntax is `Template.foo.bar = …` instead of `Template.foo.helpers({bar: …})`.
Properties of back-compat to test: You can replace an old-style helper (overwrite it). You can delete an old-style helper. We don’t have to support these capabilities, but we used them both in our test code, so apps probably do it too.
We print a deprecation once per helper. This leads to a lot of warnings! It’s helpful for porting, though developers who for some reason don’t want to port yet may want a way to disable them.
`spacebars-tests` pass.
Rename inclusion macros (with back-compat) to: Template.dynamic, Template.contentBlock, Template.elseBlock.
Update all uses and mentions of UI in the repo, unless they are there for back-compat or testing reasons.
To do: Run unit tests. Update docs for UI.dynamic. Document Template.contentBlock and Template.elseBlock.
We run the entire suite of tests as we had on
0.9.0 against an old version of compiled templates.
The test suits is found in old_templates_tests.js
Why? Packages are published in built form. With Meteor 0.9.1, we
didn't bump the major version of the 'templating' package (which
would force packages that define templates to publish new versions
of their package). Instead, we decided to keep backcompat with the
old Blaze runtime APIs.
If these tests ever break in the future, and backcompat is too hard
to achieve (or undesirable), we can simply bump the major version
of the 'templating' package, and get rid of these tests.
By choosing names like Template.registerHelper(…) and Template.instance() (instead of Blaze), we can separate the “Templates” section and the “Blaze” section of the docs.
(The test doesn’t really cover the case we encountered in iron-layout.)
It’s normal to end up calling Blaze.remove on an already-destroyed View, or a View that is not attached directly the DOM but has a parentRange (it’s just that it takes a situation like iron-layout to actually have a pointer to such a View in your code).
We test event capturing using the <video> “play” event, because it is a non-bubbling event native to modern browsers. We previously had the src URL be a video on the Internet, but even if the video could not be accessed, the test still seemed to work.
So now set the “src” to “”. Seems to work in IE 9, Firefox, Safari, Chrome.
Get rid of Template.updateTemplateInstance(view) and
Blaze.getCurrentTemplateView() in favor of view.templateInstance()
and UI.templateInstance().view.
# 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)`
Make sure inclusions with one path segment like “..” and “foo” (where foo is in the data context) don’t cause the enclosing template to re-render when the data context changes.
