Hooks for record/collection extraction in RESTAdapter.

[itsmonktastic]

Basically I wanted to override the treatment of rootKey/collectionKey, something like:

var OptionalRootKeyMixin = Ember.Mixin.create({
  extractData: function(klass, data, rootKeyProperty) {
    var rootKey = Ember.get(klass, rootKeyProperty);
    if (rootKey && data[rootKey]) {
      return data[rootKey];
    } else {
      return data;
    }
  }
});

But couldn't do this with the current hooks available. I think it might make sense to go a bit further and mimic the RESTSerializer[0] API, but wondered what people thought about this approach. Thanks!

[0]http://emberjs.com/api/data/classes/DS.RESTSerializer.html

[ebryn]

This is interesting. I'm not a big fan of trying to move into serializer territory as I believe it adds additional complexity unnecessarily. You could just override the didFind* methods and call super.

Curious what others think.

[ahacking]

I think the rootKey/collectionKey is really a Serializer/Adapter concern and not a model concern so I've felt the current approach kind of awkward.

LocalStorage doesn't need those keys, and depending on the REST api you don't need them either (in my api I have a generic results container and a type in the resource), and you certainly don't need the url on the model constructor either as again its an adapter concern.

With the recent store functionality, those configuration details should be adapter specific configuration properties.

I would prefer a separation of serializer from model and adapter. It really just abstracts the record.toJSON and record load() methods into another class. I think the serialization is again more of an adapter concern than a model concern, so either the adapter should have those methods or delegate those functions to a serializer. I have found that the built in model functions load() and toJSON() don't really align with my API design which results in additional processing transforming things to the models JSON expectations. I would also like the serializer to be able to handle server returned errors as well (eg setting server returned validation errors on the model graph).