Neat. Do you have any open-source examples of this simpler "client side application state in one place" up on GitHub? I'd love to take a peek.
I think that I'd tend to agree with your interpretation -- you write:
> [In Amber] If you have a checkbox that doesn't 1-1
> match with something you'd send to your server, you
> create an attribute on your model purely to track the
> state of that checkbox ...
That sort of approach would be against the Backbone "party line". A large part of the point is to have your canonical state for a given resource in one place: the model. If you now have both "model" and a "view-model" for the same resource, one of which has been adopted to be more checkbox-y, just so that its attributes correspond more closely with the DOM ... it would be a shame.
The allAreDone propery. It's not something you'd have in the canonical data you'd send to/from the server but exists as a property so it can be observed and so the template bindings can manipulate it.
> If you now have both "model" and a "view-model" for the same resource, one of which has been adopted to be more checkbox-y, just so that its attributes correspond more closely with the DOM ... it would be a shame.
The model is more checkboxy but the checkboxy bits are initialized from the canonical bits and your sync equivalent has to strip them back off. This is annoying but less annoying than DOM twiddling.
I think that I'd tend to agree with your interpretation -- you write:
That sort of approach would be against the Backbone "party line". A large part of the point is to have your canonical state for a given resource in one place: the model. If you now have both "model" and a "view-model" for the same resource, one of which has been adopted to be more checkbox-y, just so that its attributes correspond more closely with the DOM ... it would be a shame.