Ember router y controlador lógico

Question

Tengo curiosidad por saber exactamente lo que hay lógica en la que la capa con respecto a la nueva ruta brasa y controladores:

Si tomamos la ruta a continuación como ejemplo:

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 

Mi ExercisesNewStep1Controller está actualmente logicless:

WZ.ExercisesNewStep1Controller = Em.Controller.extend() 

el consejo recomendado parece ser la de tener la ruta acaba de hacerse cargo de la asignación de la salida correcta al ingenio controlador correcto h cualquier otra lógica en el controlador.

¿Debo refactorizar mi regulador a algo como esto:

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

Este es un ejemplo muy sencillo, pero creo que la lógica se mantiene.

Estoy un poco confundido, ¿qué hay donde con todas las capas. Creo que hay una pequeña cantidad de sobrecarga al tener que crear todos estos archivos xxxController, xxxView y el acoplamiento entre ellos.

Me encanta la brasa pero solo quiero plantear este punto.

Answer 1

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

De hecho no sé si es puesta al día con las buenas prácticas actuales, pero el modelo de gestión (creación/editar/borrar) parece no estar representados en cualquier lugar. Me parece que debe hacerse en respuesta al evento view y en los métodos connectsOutlets. Entonces tu primer ejemplo se ve bien para mí. Además, en esta diapositiva, el controlador debe contener muy poca lógica ... ¿pero qué es realmente "muy poca lógica"?

Su pregunta es muy importante para mí, ya que no tenemos ningún otro consejo, en particular de los usuarios experimentados.

Answer 2

En Sproutcore (alguien dirá lo que pasa si esto no se aplica en Ember, que se deriva de Sproutcore), los controladores casi siempre deben ser simples proxenetas. Ellos no hacen nada.

Suponiendo que esto sea válido para Ember, no movería la lógica allí.

El consejo parece ser recomendada para tener la ruta acaba de hacerse cargo de asignar la salida correcta al controlador correcto con cualquier otro lógica en el controlador.

Creo que es correcto. De los ejemplos que veo en línea, las Rutas son solo estados. Pasando al github, this link, verá que las rutas extienden los estados. Por lo tanto, los eventos de nivel de aplicación se deben manejar en sus Rutas (es decir, Estados). Es aquí donde obtendría objetos relevantes y los colocaría en controladores aplicables.

Answer 3

Tuve algunos intercambios con el equipo de Tilde, y Tom Dale nos enseñó a seguir el camino propuesto por hvgotcodes.

Pero un refinamiento producido después de una discusión con Peter Wagenet: Como respuesta a mi interrogation, Peter & Yehuda mitigated la posición que realizará del Tom explicaciones.

Así resumiría todo el cuadro que dice:

• Comportamiento deberá codificarse en un alto nivel en los controladores de eventos de ruta,
• Pero factorizados primitivas de bajo nivel puede (/ debería?) estar localizado en los controladores.

La razón es que cualquier proceso debe considerarse dentro de una ruta determinada, lo que garantiza un comportamiento coherente de toda la aplicación, sin abrir todos los procesos posibles a ninguna parte de la aplicación.