Cool, that's awesome that backbone.js is building such a strong group of developers! Apologies for pimping my own OS project but I would love to get some feedback on my app generator that creates a backbone.js powered app based on a DB schema. Particularly I'd be interested to know if the way I've organized the backbone.js code looks ok, what ways could be improved, etc. http://phreeze.com/ (you can just look at the live demo to see it running without downloading anything)
I tried alternatives to Backbone after my initial (and collaborative) creation of Todos, and I could not find anything as light, as "out of the way" as Backbone.
First of all, I'm really enjoying my time with Backbone!
Unrelatedly, but in case anyone's listening, there's something I keep wanting in Backbone, but perhaps my architecture is wrong:
// inside my view
this.model.on('change', this._onChange, this);
// later
this.model.set({ ... }, null, this);
This example uses a hypothetical version of 'set', which won't trigger 'change' events for any listeners whose context is the third argument. So, my view won't receive a 'change' event after it changes the model.
Currently, when my view wants to change something, it modifies the model and then waits to receive the 'change' event before updating what the view actually looks like. However, this feels very indirect and doesn't always work out too well (sometimes I have to resort to setting a 'ignoreNextChangeEvent' variable).
Backbone's philosophy is to keep things very loose, and let you decide how to couple Model<->View relationships; i.e., just setting a view's model doesn't explicitly update the view with new model data.
I've had what sounds like a similar situation: I want to display on the view that the model is being updated. In this case, I set a flag on the current view when starting an action, then I watch out for 'sync' events on the model; when the 'sync' message is raised, I perform an action based on the set flags.
[Addendum] A common use case where this crops up is with animations. If the user directly interacts with my view and causes the model to change, I may want the view to play an animation or otherwise respond in a context-sensitive manner. However, I usually don't want to do this if some other view has changed the model (because it wouldn't make sense or because it's off-screen).
Backbone has a lot of neat features, but when I used it I really didn't like that I had to specify the tag name, the class name, etc in a Backbone.View object. It seems like these are part of the template logic that should be in a .js file.
You don't have to specify those things in a View if you don't want to, by simply telling the View what element to attach to:
new View({el: domElement})
... but it's part of Backbone's goals -- which are further explained towards the end of the video -- that a given view has an element at all times, even before any templates may or may not have been rendered.
Always having an element means that you can worry less about view state. If all of your DOM events are delegated from the root element, you don't have to worry about whether the template has been rendered yet, which particular template might have been rendered, whether the data is available yet, and so on... The events continue to work regardless.
> when I used it I really didn't like that I had to specify the tag name, the class name, etc in a Backbone.View object.
You don't have to do it if you don't want to. Simplest way to not do it is just implement your custom `render`, and you'll have everything in an empty `div` (the default). If you want your template root to be the element's root (el/$el) as well, you can quite trivially do so by calling View#setElement from View#render:
render: function () {
return this.setElement($(renderTemplate()));
}
There you are, stick that in your parent View class and now you don't "have" to specify anything in your view (which, again, you don't have to anyway).
Also, there's no logic in that part, it's just a declarative mapping of your DOM root.
(the caveats of the guy who answered on SO still apply, this will not handle re-rendering as-is and a broken template generating multiple roots will not work correctly)
