Amber router and controller logic

Question

I'm curious to know what logic lies in that layer regarding 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 lifeless:

 WZ.ExercisesNewStep1Controller = Em.Controller.extend() 

The recommended tip seems to be that the route will simply take care of assigning the correct output to the correct controller with any other logic in the controller.

Should I reorganize 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 is complete.

I am a little confused by what lies where with all layers. I think that the overhead is small, you need to create all these xxxController, xxxView files and the relationship between them.

I like ember, but I just want to raise that moment.

Answer 1

I had several exchanges with the Tilda team, and Tom Dale taught us how to follow the suggested hvgotcodes .

But after the conversation with Peter Wagenet there was refinement: in response to my survey , Peter and Yehuda softened the position that we took from Tom’s explanations.

So, I would summarize the whole picture by saying:

• The behavior must be encoded on high-level route event handlers,
• But factorized low-level primitives can (/ should?) Be localized in controllers.

The reason is that any processing should be limited within a given route, which ensures consistent behavior of the entire application, rather than opening all possible processing for any part of the application.

Answer 2

In Sproutcore (someone will tell if this is not applicable in Ember, which comes from Sproutcore), controllers should almost always be stupid proxies. They do nothing.

Assuming this is true for Ember, I would not move logic.

The recommended tip seems to be that the route just takes care of assigning the correct socket to the right controller with any other logic in the controller.

I think that is correct. From the examples that I see online, Routes are just states. Going to github, this link , you will see that the routes expand the state. Therefore, application-level events must be handled in your Routes (i.e., States). Here you can get the corresponding objects and put them in the corresponding controllers.

Answer 3

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

Actually, I don’t know if it corresponds to the current modern working methods, but the model management (creation / editing / deleting) does not seem to be presented anywhere. It seems to me that this should be done in response to a view event, as well as in the connectsOutlets methods. So your first example looks good to me. Moreover, on this slide, the controller should contain very little logic ... but what really is "very little logic"?

Your question is very important to me as we have no other tips, especially from experienced ember users.