BusterJs is a still-in-beta library that allows for testing your Javascript.  It's got a wealth of cool features.  The browser capturing is awesome for running your Javascript directly in the browsers you choose from one runner.  You can also execute within Node.  In short, it rocks.  But, how to get this rockin' with your project, specifically your AMD RequireJs with BackboneJs combo project is the lock that must be opened before daily buster love can be had.



## Install
Buster is easily installed everywhere (but apparently not in Windows, which I have not tried):

```bash
> sudo npm install -g buster
```

The [buster docs](http://busterjs.org/docs/getting-started/) indicate not to use sudo, but I'm reckless.

## Buster Config

My directory structure looks something like:

```bash
proj/
  src/
    static/
      js/      # here are the objects under test
  test/
    tests/     # here are the tests
    buster.js  # here is the buster config
```


My previous experience with setting up [Jasmine testing with RequireJs](http://rockycode.com/blog/jasmine-unit-testing-requirejs/) was not entirely straightforward.  BusterJs was not totally straightforward either, but it felt better.  For one, it already has a runner.  I just need to give it some config (`buster.js`):

```js
var config = module.exports;
config['browser-all'] = {
  autoRun: false,
  environment: 'browser',
  rootPath: '../',
  libs: [
    'src/static/js/vendor/require-jquery-2.0.2.js',
    'src/static/js/vendor/underscore-1.3.3.js',
    'src/static/js/vendor/backbone-0.9.2.js'
  ],
  sources: [
    'src/static/js/**/*.js',
    'src/static/js/**/*.handlebars'
  ],
  tests: ['test/tests/*.js'],
  extensions: [require('buster-amd')]
};
```

A few salient points related to RequireJs / Backbone:

* `autoRun` - Turning this off allows you to [run buster tests manually](http://busterjs.org/docs/starting-testrun-manually/).  This is important from an AMD perspective, because the objects under test are loaded asynchronously.  Only once they're loaded do we want to kick off the tests.
*  `libs` - Include the RequireJs, Underscore, and Backbone files here.  `libs` will put some script tags into the browser, so require will be ready once tests start executing.  They're loaded first and in order (Underscore before Backbone is important).
* `sources` - I was having problems with my [handlebars template](http://handlebarsjs.com/) loader plugin until I realized that I need to list *all* sources, including templates, under this attribute.  And don't forget '**' for subfolders.
* `extentions` - [buster-amd](https://github.com/busterjs/buster-amd) is a buster extension that helps with the AMD module loading.  This will also require a `npm install buster-amd`.  As the [buster-amd docs](http://busterjs.org/docs/extensions/) point out, you still need to list your sources and tests normally so they're available to the buster runner, so don't leave these out thinking they'll be magically available.  

The [other configuration options/details](http://busterjs.org/docs/configuration/) are well documented.

## BusterJs Test Example

There are a few [simple examples](https://github.com/trodrigues/buster-amd-example/) of other busterjs tests that test AMD modules.  Mine looks something like:

```js
buster.spec.expose();
require.config({
  baseUrl: 'src/static/js/',
  paths: {
    text: './vendor/text-2.0.0',
    /* ... */
  }
});
```

    describe('single backbone dependency', function(run) {
      require(['Widget'], function(widget) {
        run(function() {
          it('should load', function() {
            expect(true).toEqual(true); // nothing but test execution
          });
        });
      });
    });

More from the peanut gallery:

* `buster.spec.expose()` just pushes main buster functions into the wide-open namespace to be called willy nilly.  Reckless -- again. :)
* `require.config` - it saddens me, but I have had to include this within each test file.  Others have [commented](https://groups.google.com/d/msg/busterjs/IZWItTzDT5I/AmX9wN-6oJoJ) that they could include this once in the buster.config `libs`, but it didn't work for me.  I also tried 'testHelpers', without the help they advertise.  Please let me know if it does for you and what kind of pixie dust is required.
* `baseUrl` needs to jive with your buster rootPath so that your RequireJs relative paths will match up and work in your app runtime and in the test runtime.
* `run` - notice this is called within the require callback manually.

## BusterJs Runner

If you call within the next 15 minutes, the travel-size test runner is included.  Operators are standing by.  Start your test server:

```bash
> buster server
```

That will start a server at localhost:1111.  Head 1+ of your local browsers to that address and capture them as your imprisoned slaves.  They will do your bidding when you run the tests.  Go to your project directory and run:

```bash
> buster test
```

If you've tied it all together, you should see something like:

```bash
> buster test
Chrome 21.0.1180.49, OS X 10.7 (Lion): .....                                                                            
1 test cases, 1 tests, 1 assertions, 0 failures, 0 errors, 0 timeouts
Finished in 0.02s
```

And now for a few parting tips...

## Mismatched Define Module

If you happen to include a js file in your 'libs' attribute or another section that's loaded previous to your tests running that includes a `define()` block, you're going to get stuck with this wonder:

```bash
Uncaught exception: ./src/static/js/vendor/require-jquery-2.0.2.js:1803 Uncaught Error: Mismatched anonymous define() module: function (module) {
```

As the [require docs](http://requirejs.org/docs/errors.html#mismatch) point out, to avoid this:

>Be sure to load all scripts that call define() via the RequireJS API.

## RequireJs 2.0 shim

I wasn't able to get the shim setup for getting underscore/backbone loaded and in the correct order.  Instead, I just listed these non-AMD files in the correct order under the 'libs' attribute in buster.config.

BusterJs is a still-in-beta library that allows for testing your Javascript.  It's got a wealth of cool features.  The browser capturing is awesome for runn

BusterJs with RequireJs/Backbone

BackboneJs is a great resource for creating rich UIs.  Rich means interactive.  Interactivity grows when the client can do more of the work of an application itself, becoming more reactive and dynamic to user feedback, able to be more event-driven, and hopefully more quick and responsive.  Here's a short history of how we've been creating rich UIs and a simple example of a rich UI in backbonejs



The background:

<div style="width:510px" id="__ss_12224939"> <strong style="display:block;margin:12px 0 4px"><a href="https://www.slideshare.net/rockycode/rich-uis-with-backbonejs" title="Rich UIs with BackboneJs" target="_blank" rel="noopener noreferrer">Rich UIs with BackboneJs</a></strong> <iframe src="https://www.slideshare.net/slideshow/embed_code/12224939?rel=0" width="510" height="426" frameborder="0" marginwidth="0" marginheight="0" scrolling="no"></iframe> <div style="padding:5px 0 12px"> View more <a href="https://www.slideshare.net/" target="_blank" rel="noopener noreferrer">presentations</a> from <a href="https://www.slideshare.net/rockycode" target="_blank" rel="noopener noreferrer">rockycode</a> </div> </div>

The code:

[backbone-intro on github](https://github.com/jtsnake/backbone-intro).

BackboneJs is a great resource for creating rich UIs.  Rich means interactive.  Interactivity grows when the client can do more of the work of an applicatio

Intro to BackboneJs

When you start writing applications with BackboneJS, that means that you're dealing with some dynamic UI.  There are elements being pushed into and pulled out of the DOM.  I was having problems trying to reference DOM elements that were dynamically inserted into the DOM by other Backbone views.  The fix was simple but not immediately obvious without cracking open Backbone.



Backbone View Element
---------------------

The [`el`](http://documentcloud.github.com/backbone/#View-el) property of a `Backbone.View` is the dom element within which your view contents will be displayed.  By default it's an empty div, otherwise it can be specified by a combination of `tagName`, `className`, and `id` properties.  For these options, Backbone assumes that your DOM element isn't living within the document; rather, it will be created in memory and then inserted where you later specify.

If you want to specify a pre-existing DOM element within which to insert your Backbone view contents, you set the `el` property of your view directly.  This is where I ran into problems.

Shifting Plates of the DOM
--------------------------

Backbone views assume the `$` alias is either [jQuery](http://docs.jquery.com/Main_Page)or [Zepto](http://zeptojs.com/).  They do the same thing, just use css-like selectors to get references to DOM elements.  So, I would have a view and set the `el` property to a DOM element selected by jQuery (note: examples use [RequireJS to manage dependencies](http://requirejs.org/docs/whyamd.html)), such as `MountainView.js`:

```javascript
define(function () {
  return Backbone.View.extend({
    el: $('#mountains'),
    render: function () {
      $(this.el).html(makePrettyMountains());
      return this;
    }
  });      
});
```

Problem is that earlier in the code, another view was being relied upon to insert the `#mountains` element into the DOM.  Let's say `SceneryStarterView.js` looked something like this:

```javascript
define(['MountainView'], function (MountainView) {
  return Backbone.View.extend({
    initialize: function () {
      $('body').html(makePlaceForMountains());
      var mountain = new MountainView();
      mountain.render().el;
    }
  });
});
```

It was importing (via [RequireJS](http://requirejs.org/docs/whyamd.html)) `MountainView.js`.  At import time, `$('#mountains')` was evaluated but nothing was found, because `makePlaceForMountains()` hadn't been called yet.  It was looking for `#mountains` too early!  How import the needed view, let it specify somewhere on the DOM that doesn't exist *yet* but *will* by the time it's instantiated and then rendered?  Backbone has a mechanism for this...

Into the [Asthenosphere](http://en.wikipedia.org/wiki/Asthenosphere)
--------------------------------------------------------------------

To find the answer, I had to peel back the Backbone crust and do a little dumpster diving.  When my `MountainView` is new'ed up, the constructor for `Backbone.View` is hit.  It calls a function called `_ensureElement()`:

```javascript
// Ensure that the View has a DOM element to render into.
// If `this.el` is a string, pass it through `$()`, take the first
// matching element, and re-assign it to `el`. Otherwise, create
// an element from the `id`, `className` and `tagName` proeprties.
_ensureElement : function() {
  if (!this.el) {
    var attrs = this.attributes || {};
    if (this.id) attrs.id = this.id;
    if (this.className) attrs['class'] = this.className;
    this.el = this.make(this.tagName, attrs);
  } else if (_.isString(this.el)) {
    this.el = $(this.el).get(0);
  }
}
```

Hmmmm...  If there isn't an `el` field, grab `id`, `className`, and `tagName` and create an in-memory element with `document.createElement()`.  And it's the `else if` that gives us the option we need.  *If the `el` property is a string, _now_ try and select it with jQuery*.  Perfect!  If we change our code for `MountainView.js` to reflect that one change:

```javascript
define(function () {
  return Backbone.View.extend({
    el: '#mountains',
    // render, etc
  });      
});
```

It works like a charm.  Why?  Now the order of events is:  

- `SceneryStartView` is instantiated somewhere
- It imports `MountainView` as a dependency
- `SceneryStartView` inserts the `#mountians` DOM element
- Then it news up `MountainView`
- In the constructor for `Backbone.View`, jQuery selects my string value for `el`
- One more round of hallelujah is sung!

When you start writing applications with BackboneJS, that means that you're dealing with some dynamic UI.  There are elements being pushed into and pulled o

Backbone Views in a Dynamic DOM

BackboneJS is setup to do some pretty sweet single-page app action.  And of course, a single page app will probably be wanting to talk to web services on the server.  And if your server code is doing the Java jive, then a great way to expose your REST services is via JAX-RS.  It's as easy as Mikey singin' ABC-123!



Note:  These examples use AMD-style modules in Javascript.  I personally use [RequireJS](http://requirejs.org/) for my module loading fettish.

[BackboneJS](http://documentcloud.github.com/backbone/) Model Url
--------------------

To tell a client-side [`Backbone.Model`](http://documentcloud.github.com/backbone/#Model) object where it syncs to on the server, it needs a [`url`](http://documentcloud.github.com/backbone/#Model-url) field like so (in `Cat.js`):

```javascript
define(function () {
  return Backbone.Model.extend({
    url: '/ws/cat'
  });
});
```

The `url` field can be a string literal or a function that has more meat to it.  The point is that it be awesome and point correctly to your REST endpoint exposed on the server.

If you want to fetch a model from the server, you can call [`fetch()`](http://documentcloud.github.com/backbone/#Model-fetch) directly on the model a la `myModelInstance.fetch()`, but in practice you won't know which specific model you want initially, and instead your model will be part of a [collection](http://documentcloud.github.com/backbone/#Collection-fetch).  But let's say that your model had an id of, say, 1334, and you wanted to get it off the server, you'd call `fetch()` and that call will delegate to [`Backbone.sync`](http://documentcloud.github.com/backbone/#Sync), making an HTTP GET to:

```bash
GET /ws/cat/1334
```

When you save a model by calling `myModelInstance.save()`, it delegates to `Backbone.sync` in the same way.  If it's a new object (in Backbone, that means it doesn't yet have an `id` field) that was initially created on the client and thus doesn't appear on the server yet, it'll make an HTTP POST to:

```bash
POST /ws/cat
```

If it's already an object that was requested from the server (and has, say, and id of 1334) and is now being updated based on client action, it'll make an HTTP PUT to:

```bash
PUT /ws/cat/1334
```

(BTW, HTTP DELETE works the same way as PUT.)

JAX-RS Endpoints
----------------

[JAX-RS](http://en.wikipedia.org/wiki/Java_API_for_RESTful_Web_Services) endpoints are exceedingly easy to setup.  It's all annotation-based, so you're free to rejoice.  Here's an example (It's also a [Spring `@Controller`](http://static.springsource.org/spring/docs/2.5.x/reference/beans.html)): 

```java

import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Controller;

@Controller
@Scope("singleton")
@Path("/ws/cat")
public class CatRest {

  @GET
  @Produces("application/json")
  public List<CatDto> getCats() {
    return getCatsFromSomewhere();
  }

  @POST
  @Produces("application/json")
  @Consumes("application/json")
  public CatDto createCat(CatDto dto) {
    return saveCatAndReturnInstanceWithId();      
  }

  @PUT
  @Path("/{id}")
  @Produces("application/json")
  public CatDto updateCat(CatDto dto) {
    return updateCatReturnSameInstance();
  }

  @DELETE
  @Path("/{id}")
  @Produces("application/json")
  public void deleteCat(@PathParam("id") Long id) {
    removeTheBlastedCat();
  }

}
```

This should all be fairly self-descriptive.  It matches the HTTP actions that can be made from Backbone.sync.  So what is JAX-RS doing for you.  It's allowing your methods to be exposed as rest endpoints by the simple addition of the `@GET`, `@POST`, etc annotations.  

Note that the `@Path` matches the `url` field on your Backbone model.  And `@PUT` and `@DELETE` append an `{id}` variable to the end of the path.  In the case of `@PUT`, the id gets set on the `CatDto`.  For HTTP DELETE, a body is not send, just the HTTP request, so a `@PathParam` is all you get.  

If these operations are successful, they all [respond with](http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html) HTTP 200, except for DELETE which returns 204 NO CONTENT.

JAX-RS is also dealing with the marshalling and unmarshalling from, in this case, json into and out of `CatDto`.  The `CatDto`, but like most [DTOs](http://en.wikipedia.org/wiki/Data_Transfer_Object) just provides a wrapper around your actually domain object that exposes only what you desire in your web service (ie, possibly not everything in domain objects).

And what does the DTO look like?  I'm glad you asked.

DTOs -- The Backbone / JAX-RS Gophers
-------------------------------------

Here's `CatDto.java`:

```java
import javax.xml.bind.annotation.XmlRootElement;
import java.io.Serializable;

@SuppressWarnings("serial")
@XmlRootElement
public class CatDto implements Serializable {

  private Long id;

  private String name;

  // getters and setters...

}
```

There's not much to it  -- just like a DTO should be.

By default, when JAX-RS gets some JSON in the body of an HTTP request, it's going to try and bind fields in the JSON to the DTO fields.  So, a nice piece of JSON from the client that could be unmarshalled into a `CatDto` instance would look something like:

```javascript
{
  id: 1334,
  name: 'Cotton-headed Ninnymuggins'
}
```

It's as magical as [maple syrup](http://www.youtube.com/watch?v=Fig956-MuVA)!

Binding form fields to a Backbone Model
---------------------------------------

By default, BackboneJS has no built-in ability to automatically bind the values that are entered in form fields in the UI to fields in the corresponding `Backbone.Model` object.  But, Derick Bailey has created a nice little Backbone plugin for this purpose called [Backbone.ModelBinding](https://github.com/derickbailey/backbone.modelbinding).  This is a [KnockoutJS](http://knockoutjs.com/)-inspired dom to model (and vice versa) data transfer lib.

If you don't have `Backbone.ModelBinding` on your project, you'll have to do your own setting of fields when you save with the "set and save" idiom from Backbone that will look something like:

```javascript
myModel.save({
  name: $("#name-form-field").val()
});
```

If you do want to use `Backbone.ModelBinding`, make sure you make it globally available (as a dependency [ordered](http://requirejs.org/docs/api.html#order) after Backbone itself) just put this snippet in your `Backbone.View` code:
  
```javascript
define(function () {
  return Backbone.View.extend({
    initialize: function () {
      // ...
      Backbone.ModelBinding.bind(this);
    },
    // more view goodness
  }
});
```

You should also be aware of some of the limitations of `Backbone.ModelBinding`.  For instance, it can only bind anything that a Backbone.Model can get() and set(), which doesn't include nested objects or arrays.  So, some stuff you'll have to set manually anyway if you have objects more interesting than cats.  

Also note that any inputs on the form, that are sometimes fields you don't care about or necessarily want attached to your `Backbone.Model`, show up there anyway.  So now when you call `myModelInstance.save()`, the json that gets sent to the server will be laden with extra coconuts, potentially like this:


```javascript
{
  id: 1334,
  name: 'Mittens',
  ladenWith: 'coconuts,
  africaan: true
}
```

And just between you and me, that won't work with our currently-defined `CatDto`.  It's time for a season reboot:

Backbone.ModelBinding and JAX-RS
--------------------------------

If we get these extra, albeit more exciting, fields in the json, when unmarshalling happens, we get a late Christmas present:

```text
[12/26/12 00:00:0:001] 0000000e Wr WebApplicationExceptionMapper: WebApplicationException has been caught :
Unrecognized field "laden_with" (Class CatDto), not marked as ignorable 
  at [Source: org.apache.cxf.transport.http.AbstractHTTPDestination$1@b98117; line: 1, column: 286] (through reference chain: CatDto["laden_with"])
```

"Not marked as ignorable", eh?  A couple ways to fix this.  The one requiring more typing and creating a brittle dto first.  Back to `CatDto.java`:

```java
import javax.xml.bind.annotation.XmlRootElement;
import java.io.Serializable;

@SuppressWarnings("serial")
@XmlRootElement
public class CatDto implements Serializable {

  private Long id;

  private String name;

  @XmlTransient
  private String ladeWith;

  @XmlTransient
  private Boolean africaan;

  // getters and setters...

}
```

We can label each of the undesirable fields with `@XmlTransient`, but oh the pain.

It's maybe not all that bad that this blows big chunks.  Perhaps more secure.  You want to validate input at the REST endpoints.  Maybe this is the way you personally do it.  I do it elsewhere -- in the converstion from DTOs to domain objects and with Hibernate validators on those objects.

So, for me the better option that allows me to not have to go back and mess with `CatDto.java` as much is:

```java
import javax.xml.bind.annotation.XmlRootElement;
import java.io.Serializable;
import org.codehaus.jackson.annotate.JsonIgnoreProperties;

@SuppressWarnings("serial")
@XmlRootElement
@JsonIgnoreProperties(ignoreUnknown = true)
public class CatDto implements Serializable {

  private Long id;

  private String name;

  // getters and setters...

}
```

This is whitelisting instead of blacklisting.  Lots less maintenance when more fields show up as unrecognizable.  Either way, I just use what I want on the server, so just ignore *everything* else with the [`@JsonIgnoreProperties`](http://wiki.fasterxml.com/JacksonAnnotations) annotation.

Lots of HTTP
------------

This kind of programming is really quite fun.  And it feels pretty clean.  There's lots of cool UI possibilities for single-page apps on the client.  BackboneJS and RequireJS makes handling the complexity there much more doable.  And data-handling REST endpoints on the backend are super simple.  The simplicity of the REST endpoints makes Java feel a little heavy-handed on ceremony (like it often seems these days), but JAX-RS is a great framework if Java is what you have on the backend.

BackboneJS is setup to do some pretty sweet single-page app action.  And of course, a single page app will probably be wanting to talk to web services on th

Backbone and JAX-RS

Backbone has a great inheritance mechanism.  It's as easy as Backbone.Model.extend().  This much is obvious.  Let's try a few other things, like:  Subclassing our own classes, calling to super classes, adding subclass attributes, and adding various subclasses to a collection based on a super class.



Let's just envision a potential application where we are modeling locations of different types.  In the general case, we'll refer to these things as Locations.  If it is to be a Backbone-flavored object, must [extend from Backbone](http://documentcloud.github.com/backbone/#Model-extend).  Let's just show the imagined models.

These examples are using AMD-style modules.  I personally use [RequireJS](http://requirejs.org/docs/start.html).  Note that Backbone is not AMD-compatible, so it is assume to be globally available here.

Subclass Your Subclasses
------------------------

`Location.js` might look like this:

```javascript
define(function () {
  return Backbone.Model.extend({
    // general state and behavior for all locations        
  });
});
```

In `Location.js` is where we want to put all general state and behavior across locations. Now to create a location that's specifically of type Country, we just change what we extend.  Since `Location.js` is a `Backbone.Model`, we can call extend on it as well in `Country.js`:

```javascript
define(['Location'], function (Location) {
  return Location.extend({
    // things that just a country knows and does
  });
});
```

Boom!  Just like that, `Country.js` will have everything `Location.js` does, and can add to it (by creating fields of different names than exist in `Location.js`) and can override it (by create fields of the same name).

Calling Backbone Super
----------------------

It's super!  That was easy.  

Many times, we may want to put more specific behavior in a subclass, but we still want to execute the more general code in the superclass.  For example, the `Location.js` may do certain things in its `initialize()` function that the `Country.js` wants to do as well in addition to its special country things.  Call super, causing the Location stuff to happen, the code out the rest.  

In `Country.js`:

```javascript
define(['Location'], function (Location) {
  return Location.extend({
    initialize: function () {
      this.constructor.__super__.initialize.apply(this, arguments);
      // ... do more Country-only stuff
    }
  });
});
    
```

So, latch onto the `constructor` field, then to `__super__`.  Finally, use the *actual name* of the function in the superclass that you want to call and apply it.  

And you don't even have to make the call to super as the first operation of the function. w00t!

There have been other [efforts made to simplify the call to super](http://forrst.com/posts/Backbone_js_super_function-4co), but they really aren't that much nicer so I just stick to what's built in.

Adding Attributes
-----------------

For things that aren't functions, such as an object, sometimes we want to do the equivalent of a call to super, but there's nothing to call.  Yet, we still don't want to re-state all the state of the superclass.  What's a coder to do.  Try a little [underscore](http://documentcloud.github.com/underscore/) action.  

If `Location.js`'s defaults field looks like this:

```javascript
define(function () {
  return Backbone.Model.extend({
    defaults: {
      name: 'Lame Default Location Name'
    }
  });
});
```

Then you can add more defaults in the Country and not lose the `name` field.  In `Country.js`:

```javascript
define(['Location'], function (Location) {
  return Location.extend({
    defaults: _.extend({
      more: 'goodness'
    }, Location.prototype.defaults)
  });
});  
```

Underscore's [extend](http://documentcloud.github.com/underscore/#extend) function will combine object attributes for you!  So, in the end, you'll have all of the fields in one object:


```javascript
{ 
  name: 'Lame Default Location Name',
  more: 'goodness'
}
```

This is especially great for subclassing the `Backbone.View` events attribute.


Subclasses in a Super Collection
--------------------------------

If you want a heterogeneous mix of subclasses in a super `Backbone.Collection`, you can do it.  For instance, if for some reason we wanted another Location subclass, `Ocean.js`, you'd make it extend Location:

```javascript
define(['Location'], function (Location) {
  return Location.extend({
    // big blue wet things here
  });
});
```

Now, we'll setup our collection as `World.js`:

```javascript
define(['Location'], function (Location) {
  return Backbone.Collection.extend({
    model: Location
  });
});
```

When you call `Backbone.Collection.fetch()`, `Backbone.sync` is called and a request is made to the server for your list of objects.  When the data comes back, `Backbone.Collection.parse()` is called before being saved in the collection.  Something in the incoming data must differentiate the models as being different subclasses.  For instance, countries are solid and oceans are liquid:

In `World.js`:

```javascript
define(['Location', 'Country', 'Ocean'], function (Location, Country, Ocean) {
  return Backbone.Collection.extend({
    model: Location,
    parse: function (res) {
      var self = this;
      _.each(res, function (location) {
        switch(location.phase) {
          case 'solid':
            self.add(new Country(location));
          case 'liquid':
            self.add(new Ocean(location));
          case 'gas':
            alert('kernel panic');
        }
      });
    }
  });
});
```

Now, `World.js` will contain different kinds of Locations, including Country, Ocean, and whatever other types you support.

Super Indeed
------------

Backbone does really give some niceties around inheritance.  Use it and cry with joy.

Backbone has a great inheritance mechanism.  It's as easy as Backbone.Model.extend().  This much is obvious.  Let's try a few other things.