Re: Data-Driven Javascript Controls -- What about checking checkboxes?

This is somewhat related to (and inspired by) Bitovi's recent blog post, Data-Driven JavaScript Controls.

In that post, the example deals with using an observable property (a List's length) to show/hide a "select all" checkbox. That part makes perfect sense to me: it's exactly how our app works today.

I have a question about responding to click events on that "select all" checkbox, however -- the whole "when you click 'select all', check all the checkboxes" behavior. This is one part of our app where we (intentionally) do not follow the "data-driven control" pattern.

Today, we use live-binding to control the appearance of that checkbox, but we don't use live-binding to check/uncheck the individual checkboxes under it. Instead, the control listens for ".select-all click", more-or-less like this:

1.       '.select-all click': function($selectAll) {
2.             var isChecked = $selectAll.prop('checked');
   
3.             this.element.find('.select-row').prop('checked', isChecked);
   
4.       }
   

I considered using an observable and going 100% data-driven for this, but at the time it was decided against going that route, for several reasons:

• We didn't want to add a 'selected' attribute to the model, because the model is persistent across several different views and we don't want that 'selected' flag to also be persistent. We'd need to manually set/reset/remove that attribute whenever the view gets rendered/changed/removed, and that seemed like unnecessary code which would only reduce the separation of concerns we'd gain from adding a 'selected' attribute. Further, our backend will throw an error if we accidentally send a 'selected' field to it.
  
• We didn't want to create a separate list or map just for the 'selected' attributes, because ... honestly, I don't recall why this was rejected. I think it was seen as extraneous and unnecessary to create/maintain an entirely new list, and hand it to the view, just to track the "checked" attribute of checkboxes, especially since the browser already does that. (Similarly: we don't create an observable to track the text being typed into a text input -- we only read its value on form submit.)
  
• We'd still need a handler for responding to the "select all" checkbox anyway, and that handler would effectively do the same thing as the one above -- i.e., we don't save any code for this case, unlike the example from the blog post.
• There is nothing else in the app which ever checks/unchecks any of these checkboxes. Only the end user can ever manipulate them -- and this is very unlikely to ever change, due to the nature of our app.
  

I'm now wondering whether or not this was the right decision. Almost everything else in our app is data-driven (e.g., many forms have a 'view' state and an 'edit' state -- we use an observable with live-binding to swap between them), but for lists of checkboxes we use the DOM to track the 'checked' state, at least during the time between form render and form submit. Checkboxes are admittedly pretty good at that, after all.

So, what have others done for this situation? Do you use live-binding to track/update intermediate form values (like a checkbox's checked state, a dropdown's selected option, or a text input's live value), in addition to using to show/hide elements as the blog post describes? What about in cases where one field's value affects other fields' values, as in the "select all" example?