Use dasherized resource type naming

[csantero]

This PR depends on #51, because I needed acceptance tests.

This implements the RC2 recommendation of using dasherized type names. It consists of two broad changes:

First, I added an IHttpControllerSelector that resolves the pascal-cased version of the request. The following requests will all create a UserGroupsController:

/user-groups
/user_groups
/user.groups
/UserGroups
/usergroups
/USERGROUPS

Second, I've changed the model manager's GetJsonKeyForType method to return the dasherized form of the type name. So a class UserGroup that gets pluralized to UserGroups will then get serialized with the type name user-groups.

Closes #55

[SphtKr]

Okay, I merged #51 to master, but that means I need to merge it also with the 0-4-0 branch...which I can't do from my phone, so tomorrow.

With the dasherized top level keys (really with the dasherized URLs too) we should probably be providing a subclass of kurko's JsonApiAdapter that works with our spec implementation. Even if it's just in a wiki page. Do you already have one? Or am I crazy and this won't break the off-the-shelf adapter?

[csantero]

With the dasherized top level keys (really with the dasherized URLs too) we should probably be providing a subclass of kurko's JsonApiAdapter that works with our spec implementation. Even if it's just in a wiki page. Do you already have one? Or am I crazy and this won't break the off-the-shelf adapter?

By default ember-json-api uses decamelized (underscored) strings for the URLs. I have the following sublass in my project to convert them to dasherized versions:

// app/adapters/adapter.js

import Ember from 'ember';
import JsonApiAdapter from 'ember-json-api/json-api-adapter';

export default JsonApiAdapter.extend({
  pathForType: function (type) {
    var dasherized = Ember.String.dasherize(type);
    return Ember.String.pluralize(dasherized);
  }
});

I don't need anything special to make the serializer use dasherized resource type names in my project because I dasherize all my model names at the source. But I guess there really ought to be an optional automatic conversion for people who haven't set up their models that way.

[SphtKr]

I dasherize all my model names at the source.

Confused, you can't mean App["my-model-class"] = DS.Model.extend(...), can you?

[csantero]

Confused, you can't mean App["my-model-class"] = DS.Model.extend(...), can you?

I use Ember CLI, which doesn't use the globals resolver. It resolves items as ES6 modules based on the filename they are in - I don't have App.<anything>. Instead I would have:

// app/models/user-group.js

import DS from 'ember-data';

export default DS.Model.extend({
    ...
});

[SphtKr]

Huh... So if you have a module named user-group, and in your user model you have DS.hasMany('user-group'), then? Or is it userGroup there? I have the latter, when I do it the "old" way (ahem...what the guides still say ;-) ).

[csantero]

Yes, DS.hasMany('user-group').

We started our Ember app around May 2014, when Ember CLI was still rough around the edges. I'm glad we made that decision, since Ember CLI is going to be the recommended and documented way to build Ember apps in 2.0.