-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
controllerProvider not $injecting resolve:{} parameters #1131
Comments
I think
|
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. |
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
The good thing here is that Another options is an intermediate controller, that decides what to do based on your resolved dependencies and then redirect via |
I have some data driven forms that load custom logic and templates Currently, I derive the model in a base controller and then load it into The design works, but make sub state routing (queryparams) difficult. When I found controllerProvider and templateProvider, I figured my problems
|
If you add the data to the |
However I would have to pass the param I'd to the service, and then
|
+1 |
2 similar comments
+1 |
+1 |
+1 need this |
+1's have been noted. Locking this issue to prevent further noise. |
I understand that the templateProvider has a similar issue, here's the test case:
Unknown provider: routeParamProvider <- routeParam
The text was updated successfully, but these errors were encountered: