Description
This is a real world issue that I just came across.
Let's say you have a top level model Job, with an Items collection, which has a SubItems collection:
class Job extends Backbone.Model
constructor: ->
@items = new Items()
super
parse: (attrs) ->
@items.set(attrs.items, {parse: true})
_.omit(attrs, 'items')
class Item extends Backbone.Model
constructor: ->
@subItems = new SubItems()
super
parse: (attrs) ->
@subItems.set(attrs.sub_items, {parse: true})
_.omit attrs, 'sub_items'
class Items extends Backbone.Collection
model: Item
class SubItem extends Backbone.Model
class SubItems extends Backbone.Collection
model: SubItemIf you try doing a job.fetch({parse: true}) with the correct data structure in place, when it runs the parse for the item to do the idAttribute identity check thing, the fact that you don't have the correct model you're setting the values on becomes an issue, because the parse depends that you're on the model that will ultimately be used... I feel like this is a fairly consistent (and advocated) pattern for dealing with nested models/collections... and another case where the temporary model creation causes issues.
My preferred solution would be to say that anything coming into the parse should already be in a general model format (not allowing [{model: {id:1...}, model: {id: 2...}}], only [{id:1}..., {id: 2...}]) and going back to being able to assume that the model can be identity checked based on idAttribute, and if you need otherwise - doing it on Backbone.ajax:
Backbone.ajax = function(options) {
if (options.badApi) {
if (options.type === 'GET') {
var success = options.success;
options.success = function(resp) {
return success(_.pluck(resp, 'model'));
};
}
}
return Backbone.$.ajax.apply(Backbone.$, options);
};@caseywebdev - off the top of your head, do you know roughly what revision I should look at to get the set I'd need to get this case working in the short term... was it done this way on 0.9.9?