This module provides the following classes:

• Backburner
• BucketCache
• Container
• ContainerProxyMixin
• Ember
• Ember.ActionHandler
• Ember.ActionSupport
• Ember.Application
• Ember.ApplicationInstance
• Ember.ApplicationInstance.BootOptions
• Ember.Array
• Ember.ArrayProxy
• Ember.AutoLocation
• Ember.Binding
• Ember.Checkbox
• Ember.ClassNamesSupport
• Ember.Comparable
• Ember.Component
• Ember.computed
• Ember.ComputedProperty
• Ember.ContainerDebugAdapter
• Ember.Controller
• Ember.ControllerMixin
• Ember.Copyable
• Ember.CoreObject
• Ember.CoreView
• Ember.DataAdapter
• Ember.Debug
• Ember.DefaultResolver
• Ember.EachProxy
• Ember.Engine
• Ember.EngineInstance
• Ember.Enumerable
• Ember.Error
• Ember.EventDispatcher
• Ember.Evented
• Ember.FEATURES
• Ember.Freezable
• Ember.HashLocation
• Ember.Helper
• Ember.HistoryLocation
• Ember.HTMLBars
• Ember.inject
• Ember.InjectedProperty
• Ember.Instrumentation
• Ember.LinkComponent
• Ember.Location
• Ember.Map
• Ember.MapWithDefault
• Ember.Mixin
• Ember.MutableArray
• Ember.MutableEnumerable
• Ember.Namespace
• Ember.NativeArray
• Ember.NoneLocation
• Ember.Object
• Ember.ObjectProxy
• Ember.Observable
• Ember.OrderedSet
• Ember.PromiseProxyMixin
• Ember.ProxyMixin
• Ember.Route
• Ember.Router
• Ember.Service
• Ember.String
• Ember.TargetActionSupport
• Ember.Templates.helpers
• Ember.Test
• Ember.Test.Adapter
• Ember.Test.QUnitAdapter
• Ember.TextArea
• Ember.TextField
• Ember.TextSupport
• Ember.View
• Ember.ViewMixin
• Function
• Libraries
• Registry
• RegistryProxyMixin
• RoutingService
• String

This module is a rollup of the following modules:

• ember-application
  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.
• ember-debug
• ember-extension-support
  The ContainerDebugAdapter helps the container and resolver interface with tools that debug Ember such as the [Ember Extension](https://github.com/tildeio/ember-extension) for Chrome and Firefox. This class can be extended by a custom resolver implementer to override some of the methods with library-specific code. The methods likely to be overridden are: * canCatalogEntriesByType * catalogEntriesByType The adapter will need to be registered in the application's container as container-debug-adapter:main. Example: `javascript Application.initializer({ name: "containerDebugAdapter", initialize(application) { application.register('container-debug-adapter:main', require('app/container-debug-adapter')); } }); `
• ember-glimmer
  [Glimmer](https://github.com/tildeio/glimmer) is a [Handlebars](http://handlebarsjs.com/) compatible templating engine used by Ember.js. Any valid Handlebars syntax is valid in an Ember template. ### Showing a property Templates manage the flow of an application's UI, and display state (through the DOM) to a user. For example, given a component with the property "name", that component's template can use the name in several ways: `javascript // app/components/person.js export default Ember.Component.extend({ name: 'Jill' }); ` `handlebars {{! app/components/person.hbs }} {{name}}

  {{name}}

  ` Any time the "name" property on the component changes, the DOM will be updated. Properties can be chained as well: `handlebars {{aUserModel.name}}

  {{listOfUsers.firstObject.name}}

  ` ### Using Ember helpers When content is passed in mustaches {{}}, Ember will first try to find a helper or component with that name. For example, the if helper: `handlebars {{if name "I have a name" "I have no name"}} ` The returned value is placed where the {{}} is called. The above style is called "inline". A second style of helper usage is called "block". For example: `handlebars {{#if name}} I have a name {{else}} I have no name {{/if}} ` The block form of helpers allows you to control how the UI is created based on the values of properties. A third form of helper is called "nested". For example here the concat helper will add " Doe" to a displayed name if the person has no last name: `handlebars ` Ember's built-in helpers are described under the [Ember.Templates.helpers](/api/classes/Ember.Templates.helpers.html) namespace. Documentation on creating custom helpers can be found under [Ember.Helper](/api/classes/Ember.Helper.html). ### Invoking a Component Ember components represent state to the UI of an application. Further reading on components can be found under [Ember.Component](/api/classes/Ember.Component.html).
• ember-htmlbars
• ember-metal
  This namespace contains all Ember methods and functions. Future versions of Ember may overwrite this namespace and therefore, you should avoid adding any new properties. At the heart of Ember is Ember-Runtime, a set of core functions that provide cross-platform compatibility and object property observing. Ember-Runtime is small and performance-focused so you can use it alongside other cross-platform libraries such as jQuery. For more details, see [Ember-Runtime](http://emberjs.com/api/modules/ember-runtime.html).
• ember-routing
  Ember.Location returns an instance of the correct implementation of the location API. ## Implementations You can pass an implementation name (hash, history, none) to force a particular implementation to be used in your application. ### HashLocation Using HashLocation results in URLs with a # (hash sign) separating the server side URL portion of the URL from the portion that is used by Ember. This relies upon the hashchange event existing in the browser. Example: `javascript App.Router.map(function() { this.route('posts', function() { this.route('new'); }); }); App.Router.reopen({ location: 'hash' }); ` This will result in a posts.new url of /#/posts/new. ### HistoryLocation Using HistoryLocation results in URLs that are indistinguishable from a standard URL. This relies upon the browser's history API. Example: `javascript App.Router.map(function() { this.route('posts', function() { this.route('new'); }); }); App.Router.reopen({ location: 'history' }); ` This will result in a posts.new url of /posts/new. Keep in mind that your server must serve the Ember app at all the routes you define. ### AutoLocation Using AutoLocation, the router will use the best Location class supported by the browser it is running in. Browsers that support the history API will use HistoryLocation, those that do not, but still support the hashchange event will use HashLocation, and in the rare case neither is supported will use NoneLocation. Example: `javascript App.Router.map(function() { this.route('posts', function() { this.route('new'); }); }); App.Router.reopen({ location: 'auto' }); ` This will result in a posts.new url of /posts/new for modern browsers that support the history api or /#/posts/new for older ones, like Internet Explorer 9 and below. When a user visits a link to your application, they will be automatically upgraded or downgraded to the appropriate Location class, with the URL transformed accordingly, if needed. Keep in mind that since some of your users will use HistoryLocation, your server must serve the Ember app at all the routes you define. ### NoneLocation Using NoneLocation causes Ember to not store the applications URL state in the actual URL. This is generally used for testing purposes, and is one of the changes made when calling App.setupForTesting(). ## Location API Each location implementation must provide the following methods: * implementation: returns the string name used to reference the implementation. * getURL: returns the current URL. * setURL(path): sets the current URL. * replaceURL(path): replace the current URL (optional). * onUpdateURL(callback): triggers the callback when the URL changes. * formatURL(url): formats url to be placed into href attribute. * detect() (optional): instructs the location to do any feature detection necessary. If the location needs to redirect to a different URL, it can cancel routing by setting the cancelRouterSetup property on itself to false. Calling setURL or replaceURL will not trigger onUpdateURL callbacks. ## Custom implementation Ember scans app/locations/* for extending the Location API. Example: `javascript import Ember from 'ember'; export default Ember.HistoryLocation.extend({ implementation: 'history-url-logging', pushState: function (path) { console.log(path); this._super.apply(this, arguments); } }); `
• ember-runtime
  Defines string helper methods including string formatting and localization. Unless EmberENV.EXTEND_PROTOTYPES.String is false these methods will also be added to the String.prototype as well.
• ember-testing
  The primary purpose of this class is to create hooks that can be implemented by an adapter for various test frameworks.
• ember-views
  The internal class used to create text inputs when the {{input}} helper is used with type of checkbox. See [Ember.Templates.helpers.input](/api/classes/Ember.Templates.helpers.html#method_input) for usage details. ## Direct manipulation of checked The checked attribute of an Ember.Checkbox object should always be set through the Ember object or by interacting with its rendered element representation via the mouse, keyboard, or touch. Updating the value of the checkbox via jQuery will result in the checked value of the object and its element losing synchronization. ## Layout and LayoutName properties Because HTML input elements are self closing layout and layoutName properties will not be applied. See [Ember.View](/api/classes/Ember.View.html)'s layout section for more information.