The `Backbone.Marionette.Application` object is the hub of your composite

application. It organizes, initializes and coordinate the various pieces of your

MyApp = new Backbone.Marionette.Application();

Your application needs to do useful things, like displaying content in your

regions, starting up your routers, and more. To accomplish these tasks and

started, they will run when the `start` method is called. If you

add them after the app is started, they will run immediately.

The `Application` object raises a few events during its lifecycle. These events

can be used to do additional processing of your application. For example, you

The `options` parameter is passed through the `start` method of the application

object (see below).

Once you have your application configured, you can kick everything off by

calling: `MyApp.start(options)`.

MyApp.start(options);

Every application instance comes with an instance of `Marionette.EventAggregator`

called `app.vent`.

Marionette allows you to define a module within your application,

including sub-modules hanging from that module. This is useful for creating

Marionette's module allow you to have unlimited sub-modules hanging off

your application, and serve as an event aggregator in themselves.

A module is defined directly from an Application object as the specified

name:

first instance of the module will be retained and a new

instance will not be created.

Sub-modules or child modules can be defined as a hierarchy of modules and

sub-modules all at once:

for you if they don't exist. If they do exist, though, the

existing module will be used instead of creating a new one.

You can specify a callback function to provide a definition

for the module. Module definitions are invoked immediately

MyApp.MyModule.someFunction(); //=> public data

The module's `this` argument is set to the module itself.

});

You can provide any number of custom arguments to your module, after the

module definition function. This will allow you to import 3rd party

}, LibraryNumber1, LibraryNumber2, LibraryNumberEtc);

Sometimes a module gets to be too long for a single file. In

this case, you can split a module definition across multiple

Reduce the boilerplate code of handling route events and then calling a single method on another object.

Have your routers configured to call the method on your object, directly.

Configure an AppRouter with `appRoutes`. The route definition is passed on to Backbone's standard routing

handlers. This means that you define routes like you normally would. Instead of providing a callback

You can also add standard routes to an AppRouter, with methods on the router.

App routers can only use one `controller` object. You can either specify this

directly in the router definition:

Add async / deferred rendering and template loading to Backbone.Marionette

Production: [backbone.marionette.async.min.js](https://raw.github.com/derickbailey/backbone.marionette/master/lib/backbone.marionette.async.min.js)

Note that there is no AMD/RequireJS build for Marionette.Async.

AMD/RequireJS are asynchronous by definition: **A**synchronous

The `BindTo` object provides event binding management and facilitates simple

event binding and unbinding for any object that extends from `Backbone.Events`.

var binder = _.extend({}, Backbone.Marionette.BindTo);

binder.bindTo(model, "change:foo", someCallback, someContext);

When you call `bindTo`, it returns a "binding" object that can be

used to unbind from a single event with the `unbindFrom` method:

This will unbind the event that was configured with the binding

object, and remove it from the BindTo bindings.

You can call `unbindAll` to unbind all events that were bound with the

`bindTo` method:

The `Callbacks` object assists in managing a collection of callback

methods, and executing them, in an async-safe manner.

specified context for each of the callbacks, and supplying the

provided options to the callbacks.

var callbacks = new Backbone.Marionette.Callbacks();

methods has been set to the `someContext` object, which is an optional

parameter that can be any valid JavaScript object.

You can optionally specify the context that you want each callback to be

executed with, when adding a callback:

This will run the specified callback with the `myContext` object set as

`this` in the callback, instead of `someContext`.

The `Callbacks` executes each callback in an async-friendly

manner, and can be used to facilitate async callbacks.

The `CollectionView` will loop through all of the models in the

specified collection, render each of them using a specified `itemView`,

then append the results of the item view's `el` to the collection view's

`el`.

Specify an `itemView` in your collection view definition. This must be

a Backbone view object definition (not instance). It can be any

If you do not specify an `itemView`, an exception will be thrown

stating that you must specify an `itemView`.

There may be scenarios where you need to pass data from your parent

collection view in to each of the itemView instances. To do this, provide

object, and the attributes of the object will be copied to the itemView

instance' options.

When a collection has no items, and you need to render a view other than

the list of itemViews, you can specify an `emptyView` attribute on your

This will render the `emptyView` and display the message that needs to

be displayed when there are no items.

There are several callback methods that can be provided on a

`CollectionView`. If they are found, they will be called by the

view's base methods. These callback methods are intended to be

handled within the view definition directly.

A `beforeRender` callback will be called just prior to rendering

the collection view.

});

After the view has been rendered, a `onRender` method will be called.

You can implement this in your view to provide custom code for dealing

});

This callback function allows you to know when an item / item view

instance has been added to the collection view. It provides access to

});

This method is called just before closing the view.

});

This method is called just after closing the view.

});

There are several events that will be triggered during the life

of a collection view. These are intended to be handled from code

external to the view.

Triggers just prior to the view being rendered

myView.render();

A "collection:rendered" event will also be fired. This allows you to

add more than one callback to execute after the view is rendered,

myView.render();

Triggered just before closing the view.

myView.close();

Triggered just after closing the view.

myView.close();

When an item view within a collection view triggers an

event, that event will bubble up through the parent

events or model change events, and then triggering an event

of it's own based on that.

The `render` method of the collection view is responsible for

rendering the entire collection. It loops through each of the

});

The collection view binds to the "add", "remove" and "reset" events of the

collection that is specified.

When a model is removed from a collection (or destroyed / deleted), the collection

view will close and remove that model's item view.

If you need to re-render the entire collection, you can call the

`view.render` method. This method takes care of closing all of

the child views that may have previously been opened.

By default the collection view will call jQuery's `.append` to

move the HTML contents from the item view instance in to the collection

will receive the HTML from the second parameter, the current item

view instance.

CollectionView implements a `close` method, which is called by the

region managers automatically. As part of the implementation, the