Backbone: Are Views really Controllers?

Question

I\'m building my first Backbone.js app and I\'m confused about how much responsibility I\'m supposed to give to or hide from my Views.

In my example, I\'m building

Answer 1

Have a look at this part of backbone documentation

http://documentcloud.github.com/backbone/#FAQ-tim-toady

References between Models and Views can be handled several ways. Some people like to have direct pointers, where views correspond 1:1 with models (model.view and view.model). Others prefer to have intermediate "controller" objects that orchestrate the creation and organization of views into a hierarchy. Others still prefer the evented approach, and always fire events instead of calling methods directly. All of these styles work well.

So, backbone does not take that decision for you.

I have a very similar use case (table grid with pagination, ordering, live filtering, and forms with client-side validation, master-details relations, etc.)

In my case, I first started with a Router behaving just like a controller, and quite quickly my code got a bit messy.

So I completely removed Routers (I'll add them back later, but just as an addition) and created my own controller (that in fact works as a presenter). It's just a javascript class, with Backbone.extend backed in to handle inheritance.

The idea is that the view recieves all the data it needs to display itself (model, collection, and the el in which it should be parsed), set up listener on dom events, and then executes controller methods. It never directly modifies the data nor it interacts with other views, it tells the controller to do it.

A view can have subviews, and in that case the subview only interacts with the parent view, or directly with the controller.

So far now it seems to work, but anyway things are not so simple as I expected them to be...

I hope to publish it in the next few days.