RESTAdapter Access to jqXHR / Response Headers

[kstevens715]

Let me describe the particular use-case I am currently considering. I have a reusable datatable view that allows sorting, pagination, etc. In order for this to work, I need the server to return metadata relating to the query results, such as total record count.

Currently, I'm doing this by adding attributes to my model. It works, but it's not very clean. A better solution, would be to include the metadata in the response headers. Unfortunately, the current RESTAdapter doesn't make it easy to get at the response headers.

It would be extremely useful if the jqXHR object returned by jQuery's ajax() method could somehow be made available when performing ajax calls. This would allow access to headers, response codes, etc. This would be useful whether the call resulted in success or error, and I believe it would be relevant to many more use cases than the particular one I've given as an example.

I imagine something like:

var products = App.Product.find(); // returns DS.RecordArray
var jqxhr = products.get('jqXHR')
jqxhr.getResponseHeader()

Does anyone else think this is useful and belongs in the core RESTAdapter? Thank you!

[tchak]

The role of adapter is to abstract it backend from the store. You should not be able to make a diference beween a model coming from RESTAdapter and IndexedDBAdaper. It is part of the "contract" Ember Data establish.
But I think we could have some hooks in RESTAdapter to ease filling model with some infos from headers or status codes. We definitively have some plans for a better error handeling, witch will transform in case of RESTAdapter, status codes in to meaningful backend independent errors. As for headers, we have a meta mechanism already in place, maybe it could be expanded.

[kstevens715]

@tchak, that makes sense. As long as I have access to that data, that's all I'm looking for. Is there anyway you could explain the meta mechanism that you're talking about, or perhaps point me to the place in the source? Perhaps I could work on a pull request.

[wagenet]

The adapter's didFindQuery is called with the recordArray and you can define arbitrary properties on it as you desire. This won't help with find all however since the mechanism is different and not directly tied to a single request. The default RESTAdapter does have a didError callback that gets passed the XHR object. If necessary, you can override that method for your own handling.