Closed chemt closed 12 years ago
Looked at the code, and was thinking about the best solution for this. Right now, if you call reset:true it will destroy all the keys for that model. It later goes through the keys of the model that are new and call the individual change:key event. Adding the change event when the keys are destroy isn't a big deal, but you might get double event triggers if you pass a model in with the same keys. What do you think about firing the change:key event when the key is destroyed if that key is not in the new model you're passing as well. Then it would fire the change:key event for the keys from the new model when they are set. That would keep the duplicate events from firing, but all keys that are destroyed will fire first, then the updated key events will fire.
This seems like the best course, I will see if I can implement it.
So I made this update to the set method when reset:true is set:
var _clone = this.model._data;
this.model._data = $.extend({}, arg); // erases previous model attributes without pointing to object
for(var key in _clone){
if(arg[key] === undefined) modified.push(key);
};
And it works well and is pretty fast, the problem I'm seeing now is triggering change automatically sets the view, and it can't use toString() on something that is undefined (throws an error). I can add conditionals in all those places that validate that there is something there before it tries to set the view, but that seems like the wrong way to go. Any ideas?
Field should be handeled as modified and fire
change:field
if it dissapeades in new data