4 ms·
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 no
by jfarmer 14y ago
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.
- clintjhill 14y agoThis 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.
- aneth4 14y agoGreat 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.