The controller is the data. The model is grafted onto it for convenience. This ties the view to the model to the controller which is sort of orthogonal to "separation of concerns". In my opinion at least.
That's not how I'm seeing it. The controller has data, some of which might be from the model. The view shouldn't care whether the data came from a model or not. It would be coupling if the view did care.
The view asks the controller for data. The controller might delegate that question to the model. The view shouldn't care whether the data was delegated or not; it should just get a response from the controller.
Seems like textbook object-oriented design. Otherwise how will the views update automatically when the models change? The views shouldn't know what models it needs. In fact, it seems they shouldn't know that models are a thing at all. It's just data from the controller.
This is actually where I think Ember does better than the Angular sample provided. Ember controllers hold the "data" in a "content" field on the controller (proxied). Any model can be placed there. If you do add a "people" field to the controller (as in the sample) I'd argue that does what you're describing here as "bad" because it's specifying information in the view about the model.
Great explanation. I'm not sure why (or if) ember states it so clearly.
A view calling controller.model.property is MORE tightly coupled than controller.property. The controller is tied to the view and the model as it's supposed to be. The view is not tied to the model.
No, it's not. Because a single controller over its lifetime can be bound to many different models.
The controller is glue. It brings together whichever model is appropriate at the moment with whatever view is appropriate at the moment, and makes decisions about when to change those things.
The controller is responsible for rendering the view when the data changes. It does graft the model data - and any other data you want renderable into the view. I wouldn't characterize it as "the data" however.
@rob: The controller should be the data as far as the view is concerned. Otherwise the view knows too much and the controller can't re-proxy a different model.
Knows too much about what? The view lives to present the data to the user - that's all it should know. The fact that the controller is the data is a design problem.
The data could be coming from multiple places and sources, only some of which are "models." This is true in Rails, too.
For the sanity of the view, the controller is the single point where it can get the data. It shouldn't know the nitty gritty details about where it came from, whether it's a "model," or anything else. The view is just, "Gimme the data, controller! Gimme!"
This principle is just as valid in Ember as it is in Rails. The only difference I see is that because the controller and view have to live forever, so to speak, it makes more sense for the view to pull data from the controller rather than have the controller push data to the view.
Maybe think about it this way. How is this any different than rails, really? In Rails you set goddamn instance variables in your controller actions. The view and controller are straight-up sharing state.
How is that less coupled?
This would be like the controller exposing getting and setter methods and instead of typing
<% @users.each do |user| %>
<li><%= user.name %></li>
<% end %>
you'd type
<% controller.users.each do |user| %>
<li><%= user.name %></li>
<% end %>
It seems like Ember does some "nice things" to handle the common cases and that there are additional assumptions, like maybe one model per controller (not sure I understand that), but there you go.
Ember seems less coupled all around than Rails and because of its long-running nature needs the view to poll the controller.
As mentioned above, the proxied model data is actually stored in a controller's "content" field. So that snippet is actually just shorthand for {{#each controller.content}} {{/each}}
It's not quite a shorthand as the controller can have properties of its own as well. However, the general understanding is correct, the controller proxies to the content. The controller is not the data, but it acts like it.
