A `Behavior` is an isolated set of DOM / user interactions that can be mixed into any `View` or another `Behavior`. `Behaviors` allow you to blackbox `View` specific interactions into portable logical chunks, keeping your `views` simple and your code DRY.

As you build more and more complex views, you will find that your `view` becomes less about displaying model data, and more about interactions.

Here is an example of a simple `itemView`. Let's take a stab at simplifying it, and abstracting behaviors from it.

Interaction points, such as tooltips and warning messages, are generic concepts. There is no need to recode them within your views. They are prime for abstraction into a higher level non-coupled concept, which is exactly what Behaviors provide you with.

Here is the syntax for declaring which behaviors get used within a view.

The keys in the hash are passed to `getBehaviorClass` to lookup the correct `Behavior` class.

The options for each behavior are also passed to said Behavior during initialization. The options are then stored within each behavior under `options`.

Now let's create the `DestroyWarn` behavior.

Finally, the user must define a location for where their `behaviors` are stored.

In this example you would then store your behaviors like this:

Note than in addition to extending a `View` with `Behavior`, a `Behavior` can itself use other behaviors. The syntax is identical to that used for a `View`:

Nested behaviors act as if they were direct behaviors of the parent behavior's view instance.

As a real world example, whenever in your `view` you would have `onShow`, your behavior can also have this `onShow` method defined. The same follows for `modelEvents` and `collectionEvents`. Think of your behavior as a receiver for all of the events on your view instance.

onSomeEvent: function(data) {

Any `triggers` you define on the `Behavior` will be triggered in response to the

appropriate event on the view.

Marionette.Behavior.extend({

triggers: {

'click .label': 'click:label'

}

});

`$` is a direct proxy of the views `$` lookup method.

`defaults` can be a `hash` or `function` to define the default options for your behavior.

The default options will be overridden depending on what you set as the options per behavior (this works just like a `backbone.model`).

The `view` is a reference to the view instance that the `behavior` is on.

ui elements defined on either the behavior or the view will be made available within events, and triggers. They

also are attached directly to the behavior and can be accessed within behavior methods as `this.ui`.

'Marionette.Behaviors' is a utility class that takes care of glueing your `behavior` instances to their given `View`.

The most important part of this class is that you **MUST** override the class level `behaviorsLookup` method or set the option `behaviorClass` for things to work properly.

There are two class level methods that you can override on the `Behaviors` class. The rest of the class is tied to under the hood implementation details of views.

This method defines where your behavior classes are stored. A simple implementation might look something like this.

By default the behaviors are looked up by their key value in a given views behavior hash.

In this sample (using the default `getBehaviorClass` implementation) your code will expect the following behaviors to be present in `window.Behaviors.DestroyWarn` and `window.Behaviors.ToolTip`

This method has a default implementation that is simple to override. It is responsible for the lookup of single behavior from within the `Behaviors.behaviorsLookup` or elsewhere.

This property lets you pass a `class` in for the `behavior` to use (bypassing the normal key based lookup). This is nice to have when the behavior is a dependency of the view in [requirejs](http://requirejs.org/). Properties passed in this way will be used in `getBehaviorClass`.