4 ms·

Yes Cheriot, you're probably right but we wanted to keep it easy to understand. How would you change it? Happy to improve it and make it more "best-practice" co

Yes Cheriot, you're probably right but we wanted to keep it easy to understand. How would you change it? Happy to improve it and make it more "best-practice" compliant and then share it here https://github.com/Stamplay/stamplay-foodme https://github.com/Stamplay/stamplay-foodme

aikah 12y ago
I disagree with the OP,in a system with dependency injection,it doesnt matter where the injected stuff comes from,only the fact that they are injected is important. You could have 20 services instead of one it would not make any difference. Since the details and dependencies of the services are encapsulated. I would,however separate the modal methods from the config variables, as it's 2 different concerns.But the rest is totally fine. It's a matter of opinion beyond that, there are no "best-practices",other than the fact that one should not use any data that is not injected somehow , in a controller. Same for $http.Of course one might want to abstract some business logic as the application grows,because at some point one might need to do complex stuffs when it comes to api calls(validation,...) but YAGNI over DRY. The code is still testable. Again the only thing one should NOT do in a controller is DOM manipulation,beyond that anything goes.
- Bahamut 12y ago
  I'd say you shouldn't pollute your controller with too much non-UI specific logic - oftentimes, it's worth splitting off some controller logic that is heavy into a service to test it in a more managable fashion & confine the messiness away from the controller.
cheriot 12y ago
When there are no authorities, there are no compliance issues :) The roll of controllers and link functions isn't to hold logic, it's to wire things together between the scope and services/models. For example, having a userStatus.getUserCall() is a step in the right direction. Now have the service check the response code and use the user data to create a single user object that can be returned/resolved. So your controller becomes userStatus.getUserCall().then(function(user) { $scope.user = user; }) or since angular templates are promise aware, you can reduce it to $scope.user = userStatus.getUserCall(). Now the NavbarCtrl and the MenuCtrl only need to share that one line rather than ~10!

aikah 12y ago

I disagree with the OP,in a system with dependency injection,it doesnt matter where the injected stuff comes from,only the fact that they are injected is important. You could have 20 services instead of one it would not make any difference. Since the details and dependencies of the services are encapsulated. I would,however separate the modal methods from the config variables, as it's 2 different concerns.But the rest is totally fine. It's a matter of opinion beyond that, there are no "best-practices",other than the fact that one should not use any data that is not injected somehow , in a controller. Same for $http.Of course one might want to abstract some business logic as the application grows,because at some point one might need to do complex stuffs when it comes to api calls(validation,...) but YAGNI over DRY. The code is still testable. Again the only thing one should NOT do in a controller is DOM manipulation,beyond that anything goes.

Bahamut 12y ago
I'd say you shouldn't pollute your controller with too much non-UI specific logic - oftentimes, it's worth splitting off some controller logic that is heavy into a service to test it in a more managable fashion & confine the messiness away from the controller.

cheriot 12y ago

When there are no authorities, there are no compliance issues :) The roll of controllers and link functions isn't to hold logic, it's to wire things together between the scope and services/models. For example, having a userStatus.getUserCall() is a step in the right direction. Now have the service check the response code and use the user data to create a single user object that can be returned/resolved. So your controller becomes userStatus.getUserCall().then(function(user) { $scope.user = user; }) or since angular templates are promise aware, you can reduce it to $scope.user = userStatus.getUserCall(). Now the NavbarCtrl and the MenuCtrl only need to share that one line rather than ~10!