DOMRange#setMembers was causing DOMRange#onAttached callbacks to get called, masking a bug in onViewReady where DOMRange#attached was misspelled DOMRange#isAttached.
The _onViewRendered hook fires when the View is actually rendered, not waiting until flush time or for the DOMRange to be attached. It’s not very useful as part of the public API, because you can’t do anything with it (like manipulate the generated DOM). Instead, expose onViewReady, which underlies the template “rendered” callback.
You don’t get the “wait for attached” behavior from Blaze.View anymore, you just get a plain onViewRendered callback. No onMaterialized. The template “rendered” callback implements the wait-for-attached and wait-for-afterFlush parts.
Also, if a template somehow re-renders, it won’t get extra event handlers now. And if it re-renders before being attached, something sensible will happen (like all the calls of the rendered callback will be saved for onAttached).
view.isCreatedForExpansion and view.isInRender become private.
Get rid of Template.updateTemplateInstance(view) and
Blaze.getCurrentTemplateView() in favor of view.templateInstance()
and UI.templateInstance().view.
Move Spacebars.TemplateWith to Blaze._TemplateWith. It is the official
way to give a template data, after all, but it’s a little too weird to
make public. Use it in Blaze.renderWithData, even though it doesn’t
seem like it would make a difference.
Unify UI.render/renderWithData with Blaze.render, and add
toHTMLWithData. Publicly, they take a Template or a View.
The View must be unrendered, of course. If given a Template,
constructView will be called. Privately, they take any HTMLJS
extended to be allowed to contain Templates and Views, except
null or undefined, or a function returning extended HTMLJS.
The “data” argument may be a function or a not, as in UI.With
(and unlike the old public UI.renderWithData).
Make Blaze.toText private (Blaze._toText).
Many of these (mostly in top level commands in commands-packages.js) are
not super well thought out: they use a new "doOrDie" helper to run some
function in a capture and exit if there are any messages. We really
need to get a little more thoughtful about the big picture of error
handling (combining "build" errors, network errors, catalog errors,
etc). But this at least allows the addition of more buildmessage
assertions.
At the very least, this ensures that if you edit a package.js in a local
package while "meteor run" is running, that instead of crashing the tool
it properly shows the buildmessage and lets you fix the issue.
The “rendered template” returned by UI.render and taken by UI.insert
and UI.remove is now a View (soon to be UI.View) instead of a DOMRange.
The pattern UI.insert(UI.render(Template.foo), div) is exactly the same.
The pattern Blaze.render(Template.foo).attach(div) no longer works.
If Autoupdate.autoupdateVersion is set outside of the Autoupdate
package, we wouldn't notify the client of the new version. This
patch simplifies the updating logic by only having one document
per version type.
# 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.
If we ever load javascript (uniload load or package.js parse) outside of
a buildmessage job and there's a syntax error, FancySyntaxError gets
thrown instead of properly processed. Now, we shouldn't do that (we
should only load JS inside a buildmessage job!) but our codebase isn't
currently up to that standard, so at least ensure that there's some
level of useful syntax error (albeit with an ugly internal stack trace
attached) in this case.
Before, there were some random contexts (like 'test-packages') which
didn't print downloads. Now, the default is printing, and the exception
is the automatic background updater.
(Some of these bulk contexts should probably set silent and print their
own progress bar. And maybe even do paralellism...)
Generally clean up the tropohouse.maybeDownloadPackageForArchitectures
interface. Change it to take options, remove the vestigial return
value (though really, there needs to be better error handling...)
This will mean that the tropohouse's unipackages are read-only
again (they used to be, due to extractTarGz's read-only nature, before
cross-platform merging was implemented)
This fixes the test failure of the 'run' from checkout. (It would be
nice if we weren't slowing down the rebuild in 0.9.0, but at least we
should ensure that this feature survives.)
