What a nice surprise! I started using Backbone this week, and this fixes six real issues I had with it:

- collection.fetch() now correctly calls model.parse() (I patched Backbone.Collection.prototype.parse(), but their fix is nicer)

- 'add' and 'remove' events now include the index (I had to work it out from scratch with sortedIndex())

- event 'bind' is now called 'on' (sensible as _.bind is already used for partial application)

- confusion over this.el and $()-wrapping is now cleared up

- events hash can now include functions (I like to avoid reflection where possible - even in JS)

- collection.create() now fires 'add' before the server replies (this makes writing a responsive UI much easier)

The last one is quite a significant change! Luckily my app is easy to fix, as I've only spent a few days on it.

Awesome that events hash now takes a function. I've needed that for a while, and should really get in the habit of submitting patches instead of waiting for others to do the work.

This is probably a little bit late for this release, but have you ever considered allowing arrays or strings with spaces on the value side of the events hash? This would allow you to define different functions to call in order when an event is fired, instead of just a single function that has to call them itself. I've run into a few situations where this would be useful, and seems like a very small change. Should I send a pull request?

Ha ha. That's actually already in 0.9.0, and I managed to miss it when reading through the commit list for the change log.

I've added the corresponding documentation, and added it to the change log for 0.9 as well.

http://backbonejs.org/#Events-on

I'm not familiar with the Backbone code or config. However, it sounds like you are setting an argument by specifying a function name in a string. If you want to specify multiple functions, then instead of specifying them in a string I'd say Backbone should accept either a string or a function as the argument value. That would let you define your event handler in-place, and you could define one that just calls a series of other functions.

No, that's not quite it. It's simply that you're now allowed to bind and trigger multiple event names in a single call, as in jQuery. For example:

    book.on("change:title change:author", function() {
      ...
    });

Glad to see this milestone and some pretty helpful but not very breaky changes.

What is the recommended method for dealing with the optimistic model events? If my view gets the "destroy" event but the sync fails, do I have to parse the response on the "error" event to figure out that it corresponds to the destroy action?

It might be nice to have e.g. "destroy:failed" for the benefit of views that send off these requests and want to un-change the UI and show errors if they fail.

Views that are triggering optimistic destroys can listen for "error" on their model ... or (preferably) pass a direct error callback as an option, when sending the destroy. Remember that the return value of calling "model.destroy()" is a jQuery object that can be used to chain success and error callbacks...

Note that you'll also now get the new "sync" event, after the model has been successfully deleted on the server.

Great job. Congrats!

Few questions though,

1. Would you consider adding computed properties to models and collections?

2. I have a bindModel and close methods to all my views so that close() unbinds all the methods in the views that were bound to the models/collections and it also unbinds the view events. Any reason why such a mechanism is not embedded out of the box in backbone? Or am I missing something?

1. I'm not a huge fan of treating computed properties as real data values -- because fundamentally they're not. One is part of the model's representation as a resource, and can be modified and saved back to the server, and the other is simply a computation based on the model. As peregrine suggests, I think they're much nicer as simple methods. For example:

https://github.com/documentcloud/documentcloud/blob/master/p... ... and so on.

2. Not all views display a single model -- some views show data from several, some views display an entire collection, and some views don't have any models attached. Additionally, if you tend to throw away your views at the same time you throw away your models (we tend to do this), you'll never have to unbind anything, as both are GC'd together.

It's only the case that if you tend to remove views but leave their models around to be rendered by other views later, then you need this sort of thing. And if that's the case for your app, then by all means, adding a `close()` function or the equivalent is a great idea.

1. Agreed, it force you to do things cleaner I guess.

2. The way I get around the problem is that bindModel takes (model, eventName, func, context) so having a view that represent different models isn't an issue in this case because it ends up being passed to bindModel.

example:

initialize: function () {

  this.bindModel(this.model.get('someCollection'), 'add', someFunc, this);

}

In the app I am working on, my models tend to live much longer than the views, and they usually get updates from the server.

Can you explain a bit more about #2? I'm not sure I understand fully what you mean.

1. Just add a method to a model or collection that does the computation. Javascript allows you to add methods to any object.

2. Good Question.

Right it does allow me to do that, but it doesn't get serialized and when a computed property depends on several attributes in the model, changing these attributes should also trigger the computed property change event.

The behaviour of clone has also change; instead of passing the whole instance to the constructor, it only passes the attributes. Could be worth noting for people who are upgrading (I hit an error because of that) :). Otherwise, great job!

Thanks for noticing -- I missed that in the commit logs. I've added a note about the change to the change log.