Personally, working with a big project myself, I lean toward just using
regular service objects rather than controllers. That's mainly because I
have a classical-OO / rails background, I think. I want models that handle
things like the stuff that are done in sub-controllers in the linked video.
Then I make simple controllers whose sole job is to load relevant models
and wire models into UI actions. That way if I had a Dog model, that model
would have a walk() instance method. My controller would get
Dog.find(routeParam.dogId) into the $scope, but then the view would have
stuff like ng-click="dog.walk()" on it.
I also have all of my stuff broken down into modules as well, and use
ui-router which makes it easier to have multiple controllers laying around.
But any one ui-view has a single controller. Then I just inject whatever
modules I need into the controller or wherever else is necessary.
This is kind of a potato - potahto thing probably. In general, it's a good
idea to modularize your code. In the above system, you can declare
functions outside the angular world like
function ThisCtrl(inject, inject, inject) {
}
... later inside an angular call ... $controller(ThisCtrl) ...
Whereas I do stuff like
angular.module('app.dogwalking')
.controller('ThisCtrl', function(inject, inject, inject) { ... same code})
instead. I could see a use for both, really, especially if you have some
kind of funky private function thing you want to do to hide data access
from runtime users.
e
On Thu, Aug 21, 2014 at 5:18 PM, kishorekumaru <kishorekum...@gmail.com>
wrote:
> If the link seems to complex, a simple way is to move some generic
> functions to services and include those services in your controller..
>
> Ex:
>
> //Create a new service
>
> myapp.service('myService1', function(){
> var returnService = {};
> returnService.fun1 = function(para1, para2){
> // copy paste your process
> return processedData;
> }
>
> return returnService;
> }
>
>
> // Include that service in controller
> myapp.controller('firstCntrl', ['$scope', 'myService1', function($scope,
> myService1){
>
> $scope.processedData = myService1.fun1($scope.para1, $scope.para2);
> });
>
> You can create n number of services as per your logic. Hope this helps and
> simplifies the look
>
>
> On Friday, August 22, 2014 10:00:11 AM UTC+10, kishorekumaru wrote:
>>
>> Hi I am not sure this helps
>> <http://weblogs.asp.net/dwahlin/dynamically-loading-controllers-and-views-with-angularjs-and-requirejs>
>>
>> On Friday, August 22, 2014 9:39:29 AM UTC+10, Michael Giambalvo wrote:
>>>
>>> Back at ngConf, Rachel Dale gave a talk on organizing large angular
>>> applications, in which she mentioned her team likes to use "Helper
>>> Controllers" in addition to services. https://www.youtube.com/
>>> watch?v=62RvRQuMVyg#t=1271
>>>
>>> I'm wondering what the general opinion on this technique is? I have a
>>> couple big controllers in my app that I'd like to break into smaller units,
>>> and I'm trying to figure out how to organize and have them communicate with
>>> each other. Having one controller instantiate another seems like it would
>>> solve a few of my problems, but I wonder what other problems it would
>>> create.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "AngularJS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to angular+unsubscr...@googlegroups.com.
> To post to this group, send email to angular@googlegroups.com.
> Visit this group at http://groups.google.com/group/angular.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to angular+unsubscr...@googlegroups.com.
To post to this group, send email to angular@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.
