4 ms·
There are a couple of questions about Backbone towards the bottom of the article, and this seems like a fine place to answer them: akshayr mentions that in the
by jashkenas 16y ago
There are a couple of questions about Backbone towards the bottom of the article, and this seems like a fine place to answer them:
akshayr mentions that in the context of an event handler in a View, "this" is bound to the instance of the view -- which differs from jQuery, where "this" is bound to the element that the event originated from. This is by design: it's awfully nice if methods on a View maintain their notion of "this", regardless of if they're called directly, or triggered by a DOM event. If you want to know which element was clicked, that's what "event.target" is good for, where "event" is the object that jQuery passes as the first argument to all DOM events. Here's an example that makes use of both "this", and the specific element:
var NoteList = Backbone.View.extend({
events: {
"click .note .title": "openNote"
},
openNote: function(e) {
var el = $(e.target);
var note = this.notes.get(el.attr('data-id'));
note.open();
}
...
});
The other issue raised is the lack of JSONP support in the default implementation of Backbone.sync. It would be great to make this a configurable option, without having to drop down into jQuery for simple fetches, as akshayr did. Hopefully this will be a part of the next release.
- akshayr 16y agoThe "event.target" approach is no good when the click handler is attached to a parent container with children. 'event.target' in that case will be the children instead of the parent. An example is here - http://gist.github.com/652212#file_hn http://gist.github.com/652212#file_hn comment
- akshayr 16y agoWould also love to see how you folks are unit testing MVC at DocumentCloud
- jashkenas 16y agoThe basic unit test suite for Backbone is here: http://documentcloud.github.com/backbone/test/test.html http://documentcloud.github.com/backbone/test/test.html But I'm afraid to say that we don't actually test the JavaScript in the DocumentCloud workspace very much. It's something that I'd love to do more of, but almost all of the bugs that actually occur in production aren't things that unit tests would catch -- unexpected responses from remote Ajax calls, CSS glitches in IE, etc. That said, having nice standalone models is a great start for testable code.