Remove isolatedContainer and use Ember.Application.buildRegistry. #49
Conversation
The isolatedContainer was way to finicky and caused breakage any time Ember or Ember Data decided to change what the default contents should be. This replaces the `isolatedContainer` with the container built by `Ember.Application.buildRegistry` (or `.buildContainer`) which has been available since 1.0.0. `.buildRegistry` does result in a container that is fully fleshed out but it also has a resolver attached, so in the non-integration case we replace that resolver with an empty function.
|
FYI - this test suite checks Ember 1.10, 1.11, release (1.12), beta (future 1.13), and canary (future 2.0.0). @dgeb - I'd like your feedback/review on this one... |
|
@dgeb - Ping? |
|
@rwjblue sorry for the delay - will review tonight or tomorrow morning! |
…odel (cherry picked from commit 0e90f8d)
|
@rwjblue what do you think of exporting separate methods |
|
@dgeb - Seems OK to me, what would the purpose/result be? Just to replace the |
|
@rwjblue I was thinking that it might be useful to be able to build multiple containers from the same registry. But anyway, this is all internal at this point, and my preference is to reform all of this so that tests don't even deal with registries and containers, so I'm 👍 if you just want to merge now and refactor later ... |
Remove isolatedContainer and use Ember.Application.buildRegistry.
|
@dgeb - Thanks for reviewing! |
The isolatedContainer was way to finicky and caused breakage any time Ember
or Ember Data decided to change what the default contents should be.
This replaces the
isolatedContainerwith the container built byEmber.Application.buildRegistry(or.buildContainer) which has beenavailable since 1.0.0.
.buildRegistrydoes result in a container that isfully fleshed out but it also has a resolver attached, so in the
non-integration case we replace that resolver with an empty function.