12 ms·

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_

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...

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...