Skip to content

Commit

Permalink
ApplicationInstance should create container
Browse files Browse the repository at this point in the history
Based on feedback from @stefanpenner, we moved responsibility for
creating the default container from the `Application` to the
`ApplicationInstance`. Instead, the instance points back at the
application’s registry, using it as the basis for a new container.

This commit also adds initial documentation to the application instance.
  • Loading branch information
tomdale committed Jan 22, 2015
1 parent 9c2b8d4 commit 434e9cc
Show file tree
Hide file tree
Showing 2 changed files with 34 additions and 4 deletions.
30 changes: 29 additions & 1 deletion packages/ember-application/lib/system/application-instance.js
Original file line number Diff line number Diff line change
@@ -1,16 +1,43 @@
/**
@module ember
@submodule ember-application
@private
*/

import EmberObject from "ember-runtime/system/object";
import run from "ember-metal/run_loop";

/**
The `ApplicationInstance` encapsulates all of the stateful aspects of a
running `Application`.
At a high-level, we break application boot into two distinct phases:
* Definition time, where all of the classes, templates, and other
dependencies are loaded (typically in the browser).
* Run time, where we begin executing the application once everything
has loaded.
Definition time can be expensive and only needs to happen once since it is
an idempotent operation. For example, between test runs and FastBoot
requests, the application stays the same. It is only the state that we want
to reset.
That state is what the `ApplicationInstance` manages: it is responsible for
creating the container that contains all application state, and disposing of
it once the particular test run or FastBoot request has finished.
*/

export default EmberObject.extend({
container: null,
registry: null,
customEvents: null,
rootElement: null,

init: function() {
this._super();

This comment has been minimized.

Copy link
@stefanpenner

stefanpenner Jan 22, 2015

Member

this._super.apply(this, arguments);

this.container = this.registry.container();
},

startRouting: function(isModuleBasedResolver) {
var router = this.container.lookup('router:main');
if (!router) { return; }
Expand All @@ -33,6 +60,7 @@ export default EmberObject.extend({
},

willDestroy: function() {
this._super.apply(this, arguments);
run(this.container, 'destroy');
}
});
8 changes: 5 additions & 3 deletions packages/ember-application/lib/system/application.js
Original file line number Diff line number Diff line change
Expand Up @@ -267,6 +267,7 @@ var Application = Namespace.extend(DeferredMixin, {
// Create subclass of Ember.Router for this Application instance.
// This is to ensure that someone reopening `App.Router` does not
// tamper with the default `Ember.Router`.
// 2.0TODO: Can we move this into a globals-mode-only library?
this.Router = Router.extend();
this.buildRegistry();

Expand Down Expand Up @@ -300,14 +301,15 @@ var Application = Namespace.extend(DeferredMixin, {
@return {Ember.Container} the configured container
*/
buildInstance: function() {
var container = this.__container__ = this.__registry__.container();

var instance = this.__instance__ = ApplicationInstance.create({
customEvents: get(this, 'customEvents'),
rootElement: get(this, 'rootElement'),
container: container
registry: this.__registry__
});

// TODO2.0: Legacy support for App.__container__
this.__container__ = instance.container;

return instance;
},

Expand Down

1 comment on commit 434e9cc

@stefanpenner
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

although maybe i wasn't clear, i believe my advice was for the ApplicationInstance to be initiated via the container, not to do the actually container instantiation.

Please sign in to comment.