3 ms·

In Ember.js, templates get their properties from controllers, which decorate a model. On Controllers: Controllers are used to decorate your models with display

In Ember.js, templates get their properties from controllers, which decorate a model. On Controllers: Controllers are used to decorate your models with display logic, not to handle business logic. Models have properties that are saved to the server, so they should be responsible for that. On Views: Views should be used to create reusable components or for sophisticated handling of user events. For the most part, Handlebars should get you 90% of the way. You shouldn't be making too many views in Ember.

kleinsch 13y ago
All good points. I think one of the toughest parts with Ember is that there are a lot of places to put things, so it's sometimes hard to figure out the _right_ place to put things. I'm always looking to learn from people that know more. :) We're putting as much business logic in models as possible, but are finding there are times when we need something more similar to a traditional MVC controller to coordinate actions. Handling things like form validation and coordinating multiple models doesn't seem to fit nicely in the models. How have you handled those type of situations?
- ulisesrmzroche 13y ago
  When someone submits a form with invalid data, and the server marked it as such, the record in the transaction will have the isValid flag set to false . Your controller then acts as a proxy between the model and the template. Because controllers are long-lived, the content of that controller will contain the invalid record. Now your template can have a {{#unless isValid}} and you display whatever error message there. The user keeps interacting with the form, and every time the submit button is pressed, the cycle repeats again until the record is valid, for example. The thing is that it is the model that has the to be responsible for persistence, so it is the one that marks the record as invalid. The controller would handle decorating the template, (show the error message). Now if you want to do client-side validation, you'd write a view (which really should be called component in my opinion) which would handle that logic. Notice that for the last example, all we used were templates. The view only came into play when more complicated handling of events is made (client side validation). To coordinate multiple models, you can use controller.needs (which calls another controller into play, letting you access its model and use stuff like nested resources much cleaner). http://emberjs.com/guides/controllers/dependencies-between-controllers/ http://emberjs.com/guides/controllers/dependencies-between-c...
mahmoudimus 13y ago
Hey ulisesrmzroche, You seem to possess good knowledge with Ember and its inner workings, how can I get in touch? You can get in touch with me through my profile.
- ulisesrmzroche 13y ago
  My email is ulisesrmzroche@gmail.com. I'll shoot you an email. Thanks!

kleinsch 13y ago

All good points. I think one of the toughest parts with Ember is that there are a lot of places to put things, so it's sometimes hard to figure out the _right_ place to put things. I'm always looking to learn from people that know more. :) We're putting as much business logic in models as possible, but are finding there are times when we need something more similar to a traditional MVC controller to coordinate actions. Handling things like form validation and coordinating multiple models doesn't seem to fit nicely in the models. How have you handled those type of situations?

ulisesrmzroche 13y ago
When someone submits a form with invalid data, and the server marked it as such, the record in the transaction will have the isValid flag set to false . Your controller then acts as a proxy between the model and the template. Because controllers are long-lived, the content of that controller will contain the invalid record. Now your template can have a {{#unless isValid}} and you display whatever error message there. The user keeps interacting with the form, and every time the submit button is pressed, the cycle repeats again until the record is valid, for example. The thing is that it is the model that has the to be responsible for persistence, so it is the one that marks the record as invalid. The controller would handle decorating the template, (show the error message). Now if you want to do client-side validation, you'd write a view (which really should be called component in my opinion) which would handle that logic. Notice that for the last example, all we used were templates. The view only came into play when more complicated handling of events is made (client side validation). To coordinate multiple models, you can use controller.needs (which calls another controller into play, letting you access its model and use stuff like nested resources much cleaner). http://emberjs.com/guides/controllers/dependencies-between-controllers/ http://emberjs.com/guides/controllers/dependencies-between-c...

mahmoudimus 13y ago

Hey ulisesrmzroche, You seem to possess good knowledge with Ember and its inner workings, how can I get in touch? You can get in touch with me through my profile.

ulisesrmzroche 13y ago
My email is ulisesrmzroche@gmail.com. I'll shoot you an email. Thanks!