Class Ember.Application
An instance of Ember.Application
is the starting point for every Ember
application. It helps to instantiate, initialize and coordinate the many
objects that make up your app.
Each Ember app has one and only one Ember.Application
object. In fact, the
very first thing you should do in your application is create the instance:
1 |
window.App = Ember.Application.create(); |
Typically, the application object is the only global variable. All other
classes in your app should be properties on the Ember.Application
instance,
which highlights its first role: a global namespace.
For example, if you define a view class, it might look like this:
1 |
App.MyView = Ember.View.extend(); |
By default, calling Ember.Application.create()
will automatically initialize
your application by calling the Ember.Application.initialize()
method. If
you need to delay initialization, you can call your app's deferReadiness()
method. When you are ready for your app to be initialized, call its
advanceReadiness()
method.
You can define a ready
method on the Ember.Application
instance, which
will be run by Ember when the application is initialized.
Because Ember.Application
inherits from Ember.Namespace
, any classes
you create will have useful string representations when calling toString()
.
See the Ember.Namespace
documentation for more information.
While you can think of your Ember.Application
as a container that holds the
other classes in your application, there are several other responsibilities
going on under-the-hood that you may want to understand.
Event Delegation
Ember uses a technique called event delegation. This allows the framework
to set up a global, shared event listener instead of requiring each view to
do it manually. For example, instead of each view registering its own
mousedown
listener on its associated element, Ember sets up a mousedown
listener on the body
.
If a mousedown
event occurs, Ember will look at the target of the event and
start walking up the DOM node tree, finding corresponding views and invoking
their mouseDown
method as it goes.
Ember.Application
has a number of default events that it listens for, as
well as a mapping from lowercase events to camel-cased view method names. For
example, the keypress
event causes the keyPress
method on the view to be
called, the dblclick
event causes doubleClick
to be called, and so on.
If there is a browser event that Ember does not listen for by default, you
can specify custom events and their corresponding view method names by
setting the application's customEvents
property:
1 2 3 4 5 6 7 |
App = Ember.Application.create({ customEvents: { // add support for the loadedmetadata media // player event 'loadedmetadata': "loadedMetadata" } }); |
By default, the application sets up these event listeners on the document body. However, in cases where you are embedding an Ember application inside an existing page, you may want it to set up the listeners on an element inside the body.
For example, if only events inside a DOM element with the ID of ember-app
should be delegated, set your application's rootElement
property:
1 2 3 |
window.App = Ember.Application.create({ rootElement: '#ember-app' }); |
The rootElement
can be either a DOM element or a jQuery-compatible selector
string. Note that views appended to the DOM outside the root element will
not receive events. If you specify a custom root element, make sure you only
append views inside it!
To learn more about the advantages of event delegation and the Ember view layer, and a list of the event listeners that are setup by default, visit the Ember View Layer guide.
Initializers
Libraries on top of Ember can register additional initializers, like so:
1 2 3 4 5 6 7 |
Ember.Application.initializer({ name: "store", initialize: function(container, application) { container.register('store:main', application.Store); } }); |
Routing
In addition to creating your application's router, Ember.Application
is
also responsible for telling the router when to start routing. Transitions
between routes can be logged with the LOG_TRANSITIONS
flag, and more
detailed intra-transition logging can be logged with
the LOG_TRANSITIONS_INTERNAL
flag:
1 2 3 4 |
window.App = Ember.Application.create({ LOG_TRANSITIONS: true, // basic logging of successful transitions LOG_TRANSITIONS_INTERNAL: true // detailed logging of all routing steps }); |
By default, the router will begin trying to translate the current URL into
application state once the browser emits the DOMContentReady
event. If you
need to defer routing, you can call the application's deferReadiness()
method. Once routing can begin, call the advanceReadiness()
method.
If there is any setup required before routing begins, you can implement a
ready()
method on your app that will be invoked immediately before routing
begins.
```
concatenatedProperties
Inherited from Ember.CoreObject packages/ember-runtime/lib/system/core_object.js:202
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 to Ember that 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.
customEvents
Defined in packages/ember-application/lib/system/application.js:198
The DOM events for which the event dispatcher should listen.
By default, the application's Ember.EventDispatcher
listens
for a set of standard DOM events, such as mousedown
and
keyup
, and delegates them to your application's Ember.View
instances.
If you would like additional events to be delegated to your
views, set your Ember.Application
's customEvents
property
to a hash containing the DOM event name as the key and the
corresponding view method name as the value. For example:
1 2 3 4 5 6 7 |
App = Ember.Application.create({ customEvents: { // add support for the loadedmetadata media // player event 'loadedmetadata': "loadedMetadata" } }); |
eventDispatcher
Defined in packages/ember-application/lib/system/application.js:182
The Ember.EventDispatcher
responsible for delegating events to this
application's views.
The event dispatcher is created by the application at initialization time
and sets up event listeners on the DOM element described by the
application's rootElement
property.
See the documentation for Ember.EventDispatcher
for more information.
isDestroyed
Inherited from Ember.CoreObject packages/ember-runtime/lib/system/core_object.js:267
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
Inherited from Ember.CoreObject packages/ember-runtime/lib/system/core_object.js:278
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.
resolver
Defined in packages/ember-application/lib/system/application.js:649
Set this to provide an alternate class to Ember.DefaultResolver
rootElement
Defined in packages/ember-application/lib/system/application.js:167
The root DOM element of the Application. This can be specified as an element or a jQuery-compatible selector string.
This is the element that will be passed to the Application's,
eventDispatcher
, which sets up the listeners for event delegation. Every
view in your application should be a child of the element you specify here.