By default, calling Application.create() will automatically initialize
your application by calling the 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 Application instance, which
will be run by Ember when the application is initialized.

Because 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 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.

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 bubbling 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:

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:

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!

Initializers provide an opportunity to access the internal registry, which
organizes the different components of an Ember application. Additionally
they provide a chance to access the instantiated application. Beyond
being used for libraries, initializers are also a great way to organize
dependency injection or setup in your own application.

Routing

In addition to creating your application's router, 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:

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.

Once you call this method, any time the key's value is set, your observer
will be notified. Note that the observers are triggered any time the
value is set, regardless of whether it has actually changed. Your
observer should be prepared to handle that.

The sender is the object that changed. The key is the property that
changes. The value property is currently reserved and unused. The rev
is the last property revision of the object when it changed, which you can
use to detect if the key value has really changed or not.

Usually you will not need the value or revision parameters at
the end. In this case, it is common to write observer methods that take
only a sender and key value as parameters or, if you aren't interested in
any of these values, to write an observer that has no parameters at all.

advanceReadinesspublic

Call advanceReadiness after any asynchronous setup logic has completed.
Each call to deferReadiness must be matched by a call to advanceReadiness
or the application will never become ready and routing will not begin.

When you call get on a computed property, the function will be
called and the return value will be returned instead of the function
itself.

Unknown Properties

Likewise, if you try to call get on a property whose value is
undefined, the unknownProperty() method will be called on the object.
If this method returns any value other than undefined, it will be returned
instead. This allows you to implement "virtual" properties that are
not defined upfront.

NOTE: If you do override init for a framework class like Ember.View,
be sure to call this._super(...arguments) in your
init declaration! If you don't, Ember may not have an opportunity to
do important setup work, and you'll see strange behavior in your
application.

initializer
(initializer)
public

The goal of initializers should be to register dependencies and injections.
This phase runs once. Because these initializers may load code, they are
allowed to defer application readiness and advance it. If you need to access
the container or store you should use an InstanceInitializer that will be run
after all initializers and therefore after all code is loaded and the app is
ready.

Initializer receives an object which has the following attributes:
name, before, after, initialize. The only required attribute is
initialize, all others are optional.

name allows you to specify under which name the initializer is registered.
This must be a unique name, as trying to register two initializers with the
same name will result in an error.

before and after are used to ensure that this initializer is ran prior
or after the one identified by the value. This value can be a single string
or an array of strings, referencing the name of other initializers.

An example of ordering initializers, we create an initializer named first:

It is important to note that injections can only be performed on
classes that are instantiated by Ember itself. Instantiating a class
directly (via create or new) bypasses the dependency injection
system.

instanceInitializer
(instanceInitializer)
public

Instance initializers run after all initializers have run. Because
instance initializers run after the app is fully set up. We have access
to the store, container, and other items. However, these initializers run
after code has loaded and are not allowed to defer readiness.

Instance initializer receives an object which has the following attributes:
name, before, after, initialize. The only required attribute is
initialize, all others are optional.

name allows you to specify under which name the instanceInitializer is
registered. This must be a unique name, as trying to register two
instanceInitializer with the same name will result in an error.

before and after are used to ensure that this initializer is ran prior
or after the one identified by the value. This value can be a single string
or an array of strings, referencing the name of other initializers.

See Application.initializer for discussion on the usage of before
and after.

import $ from'jquery';
exportfunctioninitialize(application) {
var userConfig, userConfigEncoded, store;
// We have a HTML escaped JSON representation of the user's basic// configuration generated server side and stored in the DOM of the main// index.html file. This allows the app to have access to a set of data// without making any additional remote calls. Good for basic data that is// needed for immediate rendering of the page. Keep in mind, this data,// like all local models and data can be manipulated by the user, so it// should not be relied upon for security or authorization.// Grab the encoded data from the meta tag
userConfigEncoded = $('head meta[name=app-user-config]').attr('content');
// Unescape the text, then parse the resulting JSON into a real object
userConfig = JSON.parse(unescape(userConfigEncoded));
// Lookup the store
store = application.lookup('service:store');
// Push the encoded JSON into the store
store.pushPayload(userConfig);
}
exportdefault {
name: 'named-instance-initializer',
initialize
};

Sometimes you need to change a value directly or indirectly without
actually calling get() or set() on it. In this case, you can use this
method instead. Calling this method will notify all observers that the
property has potentially changed value.

This method is generally very similar to calling object["key"] = value or
object.key = value, except that it provides support for computed
properties, the setUnknownProperty() method and property observers.

Computed Properties

If you try to set a value on a key that has a computed property handler
defined (see the get() method for an example), then set() will call
that method, passing both the value and key instead of simply changing
the value itself. This is useful for those times when you need to
implement a property that is composed of one or more member
properties.

Unknown Properties

If you try to set a value on a key that is undefined in the target
object, then the setUnknownProperty() handler will be called instead. This
gives you an opportunity to implement complex "virtual" properties that
are not predefined on the object. If setUnknownProperty() returns
undefined, then set() will simply set the value on the object.

Property Observers

In addition to changing the property, set() will also register a property
change with the object. Unless you have placed this call inside of a
beginPropertyChanges() and endPropertyChanges(), any "local" observers
(i.e. observer methods declared on the same object), will be called
immediately. Any "remote" observers (i.e. observer methods declared on
another object) will be placed in a queue and called at a later time in a
coalesced manner.

visit
(url, options)
Promise<ApplicationInstance, Error>public

Boot a new instance of ApplicationInstance for the current
application and navigate it to the given url. Returns a Promise that
resolves with the instance when the initial routing and rendering is
complete, or rejects with any error that occurred during the boot process.

When autoboot is disabled, calling visit would first cause the
application to boot, which runs the application initializers.

This method also takes a hash of boot-time configuration options for
customizing the instance's behavior. See the documentation on
ApplicationInstance.BootOptions for details.

ApplicationInstance.BootOptions is an interface class that exists
purely to document the available options; you do not need to construct it
manually. Simply pass a regular JavaScript object containing of the
desired options:

1

MyApp.visit("/", { location:"none", rootElement:"#container" });

Supported Scenarios

While the BootOptions class exposes a large number of knobs, not all
combinations of them are valid; certain incompatible combinations might
result in unexpected behavior.

For example, booting the instance in the full browser environment
while specifying a foreign document object (e.g. { isBrowser: true,
document: iframe.contentDocument }) does not work correctly today,
largely due to Ember's jQuery dependency.

Currently, there are three officially supported scenarios/configurations.
Usages outside of these scenarios are not guaranteed to work, but please
feel free to file bug reports documenting your experience and any issues
you encountered to help expand support.

Browser Applications (Manual Boot)

The setup is largely similar to how Ember works out-of-the-box. Normally,
Ember will boot a default instance for your Application on "DOM ready".
However, you can customize this behavior by disabling autoboot.

For example, this allows you to render a miniture demo of your application
into a specific area on your marketing website:

In this scenario, because Ember does not have access to a global document
object in the Node.js environment, you must provide one explicitly. In practice,
in the non-browser environment, the stand-in document object only needs to
implement a limited subset of the full DOM API. The SimpleDOM library is known
to work.

Since there is no access to jQuery in the non-browser environment, you must also
specify a DOM Element object in the same document for the rootElement option
(as opposed to a selector string like "body").

See the documentation on the isBrowser, document and rootElement properties
on ApplicationInstance.BootOptions for details.

Server-Side Resource Discovery

This setup allows you to run the routing layer of your Ember app in a server
environment using Node.js and completely disable rendering. This allows you
to simulate and discover the resources (i.e. AJAX requests) needed to fulfill
a given request and eagerly "push" these resources to the client.