Understanding the relationship between controllers and routes in Ember

7
votes

I'm having a bit of trouble understanding the conceptual relationship between controllers and routes in an Ember application.

I've started down the path of a pretty simple spike test to evaluate Ember, and the deeper I get into it, the more I'm seeing my routes fill up with what I'd have through should be the controller's responsibility, such as actions, wiring up models, and ultimately dispatching to a view to render a template.

The controllers are all empty, and seem to be just a placeholder for some auto-mapping requirement.

Am I missing a fundamental thing here - coming from a Rails perspective, and applying (perhaps erroneously) the "rails way" to Ember I expected my routes to define states that are represented by URLs, which would map to a controller "action".

Any pointers would be much appreciated.

1
javascriptember.js
Did you see the latest documentation ? Although they are not completely done, I think it will give you some hints. emberjs.com/guides/routing emberjs.com/guides/controllers – sly7_7
Hey no - they've updated them since I last looked, awesome thanks. I'll read over them and see if they assist :) – Michael Shimmins
Yep, I think coming from Rails world it should'nt be too hard for you to understand... after all, Yehuda is working on both ^^ – sly7_7
People say that, but I'm having a hard time understanding. Ember controllers and routes don't feel to be a near equivalent of Rails controllers and routes. Neither are views. With even the most definitive Ember example from TodoMVC, I still have a hard time figuring out the magic; in particular with routes and views – chaostheory
I don't understand how this queston doesn't have more votes. – Marco Prins

1 Answers

2
votes

While the model classes handle the objects and their state, the controller handle the state of the application itself.

A very simple use case could be that you have two states for a form: readonlyMode and modifyMode. This belongs clearly not into the model where the actual objects are defined. It is just a state of your application.

If the controller says that the state is readonlyMode, the view will render all input fields as disabled. The reverse goes for the modifyMode.

But I agree that is not always easy to decide where to put it. At then end, MVC is about concepts. Having to to put it into some kind of rules, I would say:

  • everything that represents persistent data (stored in some kind of storage/DB) is usually part of the model.
  • everything that helps to make your application stateful => controllers.