I'd like to discuss some interesting issue that surfaced after I've published my previous tutorial. Most of these come from HN.
MVC and Selectedness
Not a backbone expert, but how "correct" is it to have a presentation variable like "selected" tied to a backbone model? ...
...Second, the author makes the claim that Backbone is an MVC and makes things simpler and yet violates that. His way you literally have to go through the view, the collection, the model, a trigger, and back to the view to select a new image.
bricestacy perhaps unknowingly, summarized the way it should work in MVC.
You should go to the view, collection, model, and then your view should react back
to events from your model!
When you develop a 'desktopish' MVC application, you're not in the same game as you were when you developed serverside / frontend hybrid web applications.
Part of 'true' MVC is having a good, rich model -- and that stands for a reason. Your model should truely represent your reality; figuratively speaking, it is the body of your application, and your view is what your application wears.
If you think of a model representing whats behind a view, 'selectedness' can very well sit in a model - as long as it is a concern of your domain model. Thus, since a view reflects a model, it will also represent the state of the view.
In this example, the selectedness sits in the collection, however it may sit in the view, if that is purely a view's concern -- but not that it isn't so most of the times.
To understand why, imagine a secondary view binding to this exact 'selectedness'; in this
case you would have to bind
ViewB for the matter. This means that you cannot
compose your entire view freely - you cannot use
A model (I see collection as a certain case of a model) will always exist at the core of your application -- and that's why you want to bind against it, or any other model that keeps the selectedness state, and still keep the freedom in your views.
Here is some further relevant discussion
Some notes were made about persistence. Its true that the model doesn't give you an immediate 1:1 persistence story to
synced via Backbone. This post was not intended for that.
Even in 'proper' rich clients, there is always the question of how do you persist your client's model.
Do you use the same domain model (read: backbone Models) in your servers? do you autogenerate a version from those, to your client application? do you build an brand new derivative for your rich client, desktop application?
In this case, the main focal point is to build a domain model that can properly represent the application, without a concern for server-side (backbone sync). The idea is to take care of that at a later stage, and not let it disrupt the richness of the application itself in terms of the model's design.
Thanks to fesplugas with the sharp eyes, althought I've not used it in the CoffeeScript ports of the sample, you can (and should) use
fat arrows (=>) when you want
this to be bound -- instead of
_.bindAll. CoffeeScript gives you
native support for that. More about this in future posts.