Ember router and controller logic

Question

I am curious to know just what logic lies in which layer with respect to the new ember routing and controllers:

If we take the route below as an example:

step1: Ember.Route.extend
  route: '/step1'
    connectOutlets: (router, event) ->
      exercise = WZ.Exercise.createRecord()
      router.get('exercisesNewStep1Controller').set 'groups', WZ.store.find(WZ.Group)
      router.get('exercisesNewController').connectOutlet 'step', 'exercisesNewStep1', exercise

My ExercisesNewStep1Controller is currently logicless:

WZ.ExercisesNewStep1Controller = Em.Controller.extend()

The recommended advice seems to be to have the route just take care of assigning the correct outlet to the correct controller with any other logic in the controller.

Should I refactor my controller to something like this:

WZ.ExercisesNewStep1Controller = Em.Controller.extend
  createGroup: ->
    @set 'groups', WZ.store.find(WZ.Group)

This is a very simple example but I think the logic holds.

I am a bit confused what lies where with all the layers. I think there is a small amount of overhead by having to create all these xxxController, xxxView files and coupling between them.

I love ember but I just want to raise this point.

Wheelhorse

Answer 1

I had a few exchanges with Tilde team, and Tom Dale teached us to follow the way proposed by hvgotcodes.

But a refinement occured after a discussion with Peter Wagenet: As a reply to my interrogation, Peter & Yehuda mitigated the position we held from Tom explanations.

So I would summarize the whole picture saying:

• Behavior should be coded at a high-level in route's event handlers,
• But factorized low-level primitives may (/should?) be localized in controllers.

The reason is any processing should be scoped inside a given route, which ensure a coherent behavior of the whole app, not opening all the possible processings to any part of the app.

Prepositor

Answer 2

In Sproutcore (someone will speak up if this doesn't apply in Ember, which derives from Sproutcore), controllers should almost always just be dumb proxies. They don't do anything.

Assuming that holds true for Ember, I wouldn't move the logic there.

The recommended advice seems to be to have the route just take care of assigning the correct outlet to the correct controller with any other logic in the controller.

I think that is correct. From the examples I see online, Routes are just states. Going to github, this link, you will see that Routes extend States. So application level events should be handled in your Routes (i.e. States). It's here where you would get relevant objects and put them in applicable controllers.

Accouter

Answer 3

https://speakerdeck.com/u/tomdale/p/emberjs-more-than-meets-the-eye slide 55.

In fact I don't know if it's up-to-date with current good practices, but the model management (creation/edit/delete) seems to be not represented anywhere. It seems to me that it must be done in response to view event, and in the connectsOutlets methods. So your first example looks good for me. Moreover, in this slide, the controller should contain very little logic... but what is really "very little logic"?

Your question is very important for me, as we don't have any other advices, particularly from experienced ember users.

Rawdin