This gist challenges keeping template and logic separate.
From my perspective, there are two sets of logic that exist in user interfaces:
- Interactive (the kind of bindings that perform things like animations and validation)
- Business (updating data and talking to servers)
My current and past beliefs are that views are the content and controllers are the business logic. Content should be interactive not static -- if I click on X, then Y should happen. This binding does not belong in a controller; it is part of the markup.
Rant:
Back when our UI's were generating content on the server-side, all views were static HTML going downstream. However, once they made it to the client side, we had a single endpoint where JavaScript bindings would take place. This has since changed with client side UI's, we now have many end-points since we render and bind every view. This means we need to modularize all of those interactions with the content itself.
Pros:
- No longer maintaining two files for one view/template combination
Cons:
- Attaching events onto partials gets interesting but it always does
- Goodbye linting =(
- The caveat for this is that if anything can be abstracted to a jQuery plugin, it should be (and thus instantiated via Builder)
- Otherwise, it will be a sad one-off fashion that cannot be linted
If you are asking, but what about using a template for two views? (in the backbone sense) My response is nothing has changed -- the only difference is instead of being a template/view difference, they are now both views. Just load the common view as a partial, problem solved.