Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>It seems you are not injecting the <code>$modal</code> service as a dependency.</p> <p>How to "inject a service"?</p> <p>Consider the <code>function</code> you are trying to use the service... you should declare it like this:</p> <pre><code>['$modal', function($modal) { // $modal has been injected here, you can use it }] </code></pre> <p><hr></p> <h3>Edit:</h3> <p>I've studied you Plunk now... it is overcomplicating simple things, and reveals some miscomprehensions about AngularJS concepts (controller, scope, etc.)</p> <p>Also, it was using Bootstrap's 3 CSS - which is not compatible with AngularJS Bootstrap currently. I've changed the CSS link to Bootstrap 2.</p> <p>See how it can be much much more simple and effective: <a href="http://plnkr.co/edit/YFuAA5B65NZggd6fxjCh?p=preview">http://plnkr.co/edit/YFuAA5B65NZggd6fxjCh?p=preview</a></p> <p>I'd recommend studying this document carefully, from start to finish: <a href="http://docs.angularjs.org/guide/concepts">http://docs.angularjs.org/guide/concepts</a></p> <p>This video is also very very good, but it does not provide deeper insight into the concepts: <a href="http://weblogs.asp.net/dwahlin/archive/2013/04/12/video-tutorial-angularjs-fundamentals-in-60-ish-minutes.aspx">http://weblogs.asp.net/dwahlin/archive/2013/04/12/video-tutorial-angularjs-fundamentals-in-60-ish-minutes.aspx</a></p> <hr> <p>Basically, the error message was telling that you were trying to inject a service into something (the "ModalController", in your case) - but this service was not found.</p> <p>"How I was trying to inject?" - you may ask. The answer is: every parameter you require in a Controller function is a "dependency" to be "injected" - and AngularJS "injector" service performs this task. This is how "$scope" parameter magically receives a "scope" - it is the injector working behind the scenes.</p> <p>In you ModalController, the injector was trying to satisfy both the "$modalInstance" and the "items" dependencies (remove the "$modalInstance" parameter - the error message will change to "itemsProvider not found")...</p> <p>If you want to receive dependencies like this, through the "magical" work of the injector, you need to create/declare services with these names... (or properly use the "resolve" attribute as you were trying to do) ...</p> <p>...but this is not needed in this case at all. You just want access to "items", and return a selected item. You were also trying to close/dismiss the modal programatically.</p> <p>You could resolve dependencies through the "resolve" attribute, but why complicate so much what can be achieved with simplicity? Just use the "scope" attribute instead, and provide the scope to the modal - it will have access to its properties. The modal also automatically adds "$close" and "$dismiss" functions to the scope, so you can easily use these functions.</p> <p>You were trying to pass attributes from the main scope to the modal scope by injecting them as services into the modal controller! :-) You were trying to inject the own modal instance into its controller!!!</p> <p>So, your main issue is related to the <code>$injector</code> - it worths studying what is this <strong>inject</strong> thing all about - it is well explained in the documented I linked above.</p> <p>"Inject a service" is not as simple as "passing a variable to a function". You were almost there through the "resolve" attribute, but as I've said - really not needed for this simple case.</p> <p>I've created another Plunker without using "scope", and keeping the "resolve"... it is not possible to inject the "modalInstance" as we do with "items":</p> <pre><code>'$modalInstance': function() { return modalInstance; } </code></pre> <p>...because it is still <code>undefined</code> at this moment... we could workaround by just calling <code>$scope.$close</code> in the ModalController (and not injecting the modal)...</p> <p>...or, like I did, injecting it through a function... very crazy, but it works:</p> <p><a href="http://plnkr.co/edit/9AhH6YFBUmhYoUDhvnhQ?p=preview">http://plnkr.co/edit/9AhH6YFBUmhYoUDhvnhQ?p=preview</a></p> <p>...I would never do like this... it is just for learning purposes!</p> <hr> <p>At last but not least: by adding <code>ng-controller</code> in the template file, you are requiring the ModalController twice... you already stated it in the modal configuration. But through the modal configuration, you can have the dependency injection through the resolver - while through the template you don't have the "resolve" thing applied.</p> <h2>Update:</h2> <p>As pointed in the comments by Mahery, <code>$modalInstance</code> is made available for injection in the controller by AngularUI Bootstrap implementation. So, we don't need any effort ro "resolve" or make it available somehow.</p> <p>Here is the updated Plunker: <a href="http://plnkr.co/edit/BMfaFAWibHphDlZAkZex?p=preview">http://plnkr.co/edit/BMfaFAWibHphDlZAkZex?p=preview</a></p> <p>Indeed, the error was happening mainly due to the "ng-controller" atttribute in the template. The controller created through this way does not receive the "AngularUI treatment". Only the controller specified in the modal <strong>options</strong> receives the "treatment" where <code>$modalInstance</code> is provided...</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. COExcellent explanation. Can you tell me why you say the second plunker is "crazy, but it works"? Seems to me that the second method passes the scope items to the modal, where the other accesses the items on scope directly. I'm just trying to understand scope further I guess; or rather, proper usage of it. I'll definitely be giving all of that concepts link a more thorough read. Is there an advantage to not using resolve? Or perhaps a better question may be, when is a good time to use and when is it not beneficial? Thanks again for the in depth explanation.
      singulars
    2. CO"Crazy, but it works" - because it is too much complication to perform such a simple task. That implementation only makes sense for study - to play and see how things work - but never for real in a **simple case** like this. "Resolve" is available as a way to inject stuff in the controller, when it is instantiated. Use it when you **need** it. There is no "advantage" in using an advanced resource without needing it. The only "advantage" is that, when you **need** to inject something into the controller, "resolve" offers a way to do it. I am using plenty of modals and I have not needed it yet.
      singulars
    3. COThe only usage of "resolve" I've done by now was not for modals, but for [route configuration](http://docs.angularjs.org/api/ngRoute.$routeProvider#when). I've read [this article about dynamically loading controllers](http://weblogs.asp.net/dwahlin/archive/2013/05/22/dynamically-loading-controllers-and-views-with-angularjs-and-requirejs.aspx), took some time to study it in depth, and adapted its solution to my own needs. In this case, I can't imagine how to perform the task without "resolve" - in other words, we really **need** it to solve the problem.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload