A recent change fixed the behavior of `Template.currentData`
and `Template.parentData` in event handlers and helpers.
These are tests for the new, correct behavior.
(The old behavior read the data of the template instance.
The new behavior read the data context around the DOM node
where the event or helper ran)
Fill in all packages without README.md files with a short
README.md mentioning that this is an internal Meteor package.
Break up the top paragraph of a couple of existing README.md
files to be proper long description.
There is more work to do here, involving line wrapping and the like.
If you Blaze.remove a View that is a template rendered by Blaze.renderWithData, or included with an implicit “with” as in `{{> myTemplate someData}}`, Blaze will now remove the DOM of the template, and also remove the implicit “with” (in both cases).
As background, Blaze.remove only works on Views that were attached directly under a DOM element, not inside another View. Blaze.render always attaches the resulting View directly under a DOM element, but Blaze.renderWithData creates a “with” View around the template View. Previously, you could Blaze.remove the “with” View (which is returned by renderWithData), but if you got access to the template’s View some other way and tried to remove it directly, nothing would happen. Now, the correct thing happens (the View is destroyed and the DOM is removed).
In the future, we should consider whether Blaze.remove should work on arbitrary Views, not just Views attached under a DOM element.
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.
