Class Ember.DefaultResolver

public
Extends: Ember.Object
Defined in: packages/ember-application/lib/system/resolver.js:40
Module: ember

The DefaultResolver defines the default lookup rules to resolve container lookups before consulting the container for registered items:

  • templates are looked up on Ember.TEMPLATES
  • other names are looked up on the application after converting the name. For example, controller:post looks up App.PostController by default.
  • there are some nuances (see examples below)

How Resolving Works

The container calls this object's resolve method with the fullName argument.

It first parses the fullName into an object using parseName.

Then it checks for the presence of a type-specific instance method of the form resolve[Type] and calls it if it exists. For example if it was resolving 'template:post', it would call the resolveTemplate method.

Its last resort is to call the resolveOther method.

The methods of this object are designed to be easy to override in a subclass. For example, you could enhance how a template is resolved like so:

1
2
3
4
5
6
7
8
9

App = Ember.Application.create({
  Resolver: Ember.DefaultResolver.extend({
    resolveTemplate: function(parsedName) {
      var resolvedTemplate = this._super(parsedName);
      if (resolvedTemplate) { return resolvedTemplate; }
      return Ember.TEMPLATES['not_found'];
    }
  })
});

Some examples of how names are resolved:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

'template:post'           //=> Ember.TEMPLATES['post']
'template:posts/byline'   //=> Ember.TEMPLATES['posts/byline']
'template:posts.byline'   //=> Ember.TEMPLATES['posts/byline']
'template:blogPost'       //=> Ember.TEMPLATES['blogPost']
                          //   OR
                          //   Ember.TEMPLATES['blog_post']
'controller:post'         //=> App.PostController
'controller:posts.index'  //=> App.PostsIndexController
'controller:blog/post'    //=> Blog.PostController
'controller:basic'        //=> Ember.Controller
'route:post'              //=> App.PostRoute
'route:posts.index'       //=> App.PostsIndexRoute
'route:blog/post'         //=> Blog.PostRoute
'route:basic'             //=> Ember.Route
'view:post'               //=> App.PostView
'view:posts.index'        //=> App.PostsIndexView
'view:blog/post'          //=> Blog.PostView
'view:basic'              //=> Ember.View
'foo:post'                //=> App.PostFoo
'model:post'              //=> App.Post

Show:

concatenatedProperties public

Module: ember

Inherited from Ember.CoreObject packages/ember-runtime/lib/system/core_object.js:272

Defines the properties that will be concatenated from the superclass (instead of overridden).

By default, when you extend an Ember class a property defined in the subclass overrides a property with the same name that is defined in the superclass. However, there are some cases where it is preferable to build up a property's value by combining the superclass' property value with the subclass' value. An example of this in use within Ember is the classNames property of Ember.View.

Here is some sample code showing the difference between a concatenated property and a normal one:

1
2
3
4
5
6
7
8
9
10
11
12
13

App.BarView = Ember.View.extend({
  someNonConcatenatedProperty: ['bar'],
  classNames: ['bar']
});

App.FooBarView = App.BarView.extend({
  someNonConcatenatedProperty: ['foo'],
  classNames: ['foo']
});

var fooBarView = App.FooBarView.create();
fooBarView.get('someNonConcatenatedProperty'); // ['foo']
fooBarView.get('classNames'); // ['ember-view', 'bar', 'foo']

This behavior extends to object creation as well. Continuing the above example:

1
2
3
4
5
6

var view = App.FooBarView.create({
  someNonConcatenatedProperty: ['baz'],
  classNames: ['baz']
})
view.get('someNonConcatenatedProperty'); // ['baz']
view.get('classNames'); // ['ember-view', 'bar', 'foo', 'baz']

Adding a single property that is not an array will just add it in the array:

1
2
3
4

var view = App.FooBarView.create({
  classNames: 'baz'
})
view.get('classNames'); // ['ember-view', 'bar', 'foo', 'baz']

Using the concatenatedProperties property, we can tell Ember to mix the content of the properties.

In Ember.View the classNameBindings and attributeBindings properties are also concatenated, in addition to classNames.

This feature is available for you to use throughout the Ember object model, although typical app developers are likely to use it infrequently. Since it changes expectations about behavior of properties, you should properly document its usage in each individual concatenated property (to not mislead your users to think they can override the property in a subclass).

isDestroyed public

Module: ember

Inherited from Ember.CoreObject packages/ember-runtime/lib/system/core_object.js:410

Destroyed object property flag.

if this property is true the observers and bindings were already removed by the effect of calling the destroy() method.

isDestroying public

Module: ember

Inherited from Ember.CoreObject packages/ember-runtime/lib/system/core_object.js:422

Destruction scheduled flag. The destroy() method has been called.

The object stays intact until the end of the run loop at which point the isDestroyed flag is set.

mergedProperties public

Module: ember

Inherited from Ember.CoreObject packages/ember-runtime/lib/system/core_object.js:341

Defines the properties that will be merged from the superclass (instead of overridden).

By default, when you extend an Ember class a property defined in the subclass overrides a property with the same name that is defined in the superclass. However, there are some cases where it is preferable to build up a property's value by merging the superclass property value with the subclass property's value. An example of this in use within Ember is the queryParams property of routes.

Here is some sample code showing the difference between a merged property and a normal one:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

App.BarRoute = Ember.Route.extend({
  someNonMergedProperty: {
    nonMerged: 'superclass value of nonMerged'
  },
  queryParams: {
    page: {replace: false},
    limit: {replace: true}
  }
});

App.FooBarRoute = App.BarRoute.extend({
  someNonMergedProperty: {
    completelyNonMerged: 'subclass value of nonMerged'
  },
  queryParams: {
    limit: {replace: false}
  }
});

var fooBarRoute = App.FooBarRoute.create();

fooBarRoute.get('someNonMergedProperty');
// => { completelyNonMerged: 'subclass value of nonMerged' }
//
// Note the entire object, including the nonMerged property of
// the superclass object, has been replaced

fooBarRoute.get('queryParams');
// => {
//   page: {replace: false},
//   limit: {replace: false}
// }
//
// Note the page remains from the superclass, and the
// `limit` property's value of `false` has been merged from
// the subclass.

This behavior is not available during object create calls. It is only available at extend time.

This feature is available for you to use throughout the Ember object model, although typical app developers are likely to use it infrequently. Since it changes expectations about behavior of properties, you should properly document its usage in each individual merged property (to not mislead your users to think they can override the property in a subclass).

namespace public

Module: ember

Defined in packages/ember-application/lib/system/resolver.js:113

This will be set to the Application instance when it is created.