controllerProvider not $injecting resolve:{} parameters

[Nthalk]

I understand that the templateProvider has a similar issue, here's the test case:

$stateProvider.state({
    url: "/",
    controllerProvider: function(resolveParam){},
    resolve: {resolveParam: function(){ return true;}}
});

Unknown provider: routeParamProvider <- routeParam

[tylkomat]

I think controllerProvider just works with $stateParams as it is meant to just return a name of the controller. For resolve dependency injection use just controller.

$stateProvider.state({
    url: "/",
    controller: function(resolveParam){},
    resolve: {resolveParam: function(){ return true;}}
});

[Nthalk]

I understand how it work now. Perhaps I should have marked this as a feature enhancement.

If I specify different controllers, the odds are that they might deal with different models, or require a model to determine the controller name.

I thought it was nice to have the routing layer resolve those dependencies, then decide a controller, optionally with those dependencies, and then feed those into the controller.

[tylkomat]

I don't understand what you want to achieve, Usually you decide based on url parameters which controller should handle the call. This you can do with controllerProvider then the resolved dependencies are injected into the specified controller.

angular.module('app').config(
    function($stateProvider) {
        $stateProvider.state('main', {
            url: '/:controller',
            templateUrl: 'views/main.html',
            controllerProvider: function($stateParams) {
                // decide on controller based on params
                return controllerName; // i.e. myController
            },
            resolve: {
                myDependency: function() {
                    // something to resolve
                }
            }
        };
    }
).controller('myController', function($scope, myDependency, otherDependency) {
    // do something
});

The good thing here is that otherDependency is still resolved in the controller, while it was not before resolved in the router. With this you can for example define another controller, that only depends on $scope and myDependency or only myDependency or not at all. The controllerProvider just decides on the name. What your controller then needs is up to the controller itself.

Another options is an intermediate controller, that decides what to do based on your resolved dependencies and then redirect via $state.go() to another state, with or without changing the URL.

[Nthalk]

I have some data driven forms that load custom logic and templates
(business requirement).

Currently, I derive the model in a base controller and then load it into
the app with a transclude el with the dataform.controller and
dataform.templateUrl.

The design works, but make sub state routing (queryparams) difficult.

When I found controllerProvider and templateProvider, I figured my problems
were over, until I realized that they did not wait for the dataform model
to load. So... Why not?
On Jun 6, 2014 7:30 AM, "Matthias Tylkowski" notifications@github.com
wrote:

I don't understand what you want to achieve, Usually you decide based on
url parameters which controller should handle the call. This you can do
with controllerProvider then the resolved dependencies are injected into
the specified controller.

angular.module('app').config(
function($stateProvider) {
$stateProvider.state('main', {
url: '/:controller',
templateUrl: 'views/main.html',
controllerProvider: function($stateParams) {
// decide on controller based on params
return controllerName; // i.e. myController
},
resolve: {
myDependency: function() {
// something to resolve
}
}
};
}
).controller('myController', function($scope, myDependency, otherDependency) {
// do something
});

The good thing here is that otherDependency is still resolved in the
controller, while it was not before resolved in the router. With this you
can for example define another controller, that only depends on $scope
and myDependency or only myDependency or not at all. The
controllerProvider just decides on the name. What your controller then
needs is up to the controller itself.

—
Reply to this email directly or view it on GitHub
#1131 (comment)
.

[tylkomat]

If you add the data to the scope you should be able to access it or create a service to hold that data.

[Nthalk]

However I would have to pass the param I'd to the service, and then
controllerProvider would have to allow the return of a promise, which it
does not currently.
On Jun 6, 2014 8:19 AM, "Matthias Tylkowski" notifications@github.com
wrote:

If you add the data to the scope you should be able to access it or
create a service to hold that data.

—
Reply to this email directly or view it on GitHub
#1131 (comment)
.

[cjroth]

+1

[SelrahcD]

+1

[fvelosa]

+1

[nihique]

+1 need this

[nateabele]

+1's have been noted. Locking this issue to prevent further noise.