Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: