If you have radio buttons in corporation with "ng-repeat", the radio buttons do not reflect result to "ng-model".
E.g.
<table>
<tr ng-repeat="option in options">
<td>
<input type="radio" ng-model="selectedOption" value="{{option.value}}"
id="option-{{option.value}}">
<label for="option-{{option.value}}">{{option.description}}</label>
</td>
</tr>
</table>
In the example above it is possible to select all radio buttons at the same time even if they have same "ng-model".
angular 1.0.1
That happens because ng-repeat
creates a new scope. Basically, each <input>
is creating a selectedOption
value on its own inner scope. To work around that, create a new container object for that value. For example, you could declare in your controller:
$scope.data = {selectedOption: x};
And then in your template, use ng-model="data.selectedOption"
(hopefully with a name more descriptive than "data" :)). Since data
is never directly assigned on inner scopes, it's not overridden.
Albeit not particularly intuitive at first, I suspect this is intended behavior.
Interesting.
That works! Thanks a lot! :)
I am sorry it is stoopid (i think you meant stupid). Perhaps you could design a better framework. Go for it. :-)
Could someone explain why wrapping the property in another object fixes this problem? This indirectly helped me solve a weird issue I had with a directive and a controller trying to access the same data.
@robschley - if you "set" a single variable it will be confined to the current scope. If you "get" it will try to find the variable in the parent scopes, too. So when you check these checkboxes-
<input type="checkbox" ng-model="foo">
-- will set "foo" in the current scope<input type="checkbox" ng-model="wrapper.foo">
-- will GET "wrapper" from the parent scope (by reference), then set "foo" on the wrapperPlease add this to the documentation. I spent too long searching and experimenting before finding this.
Thanks!
Same here, this issue saved my day but I spent a lot time to find this.
Same here, this issue saved my day but I spent a lot time to find this.
Rather than wrapping it in an object, you can also reference your parent's scope directly.
I've set up an example here: http://plnkr.co/edit/aqTUSBEvbJafX0r3luXy
This video helped me: http://egghead.io/video/angularjs-the-dot/
Had the same problem and tried tynman solution
$parent.selectOption
,
worked straight.
I'm posting it just to actually show the solution (better I think than a link ...)
worked for me! thanks alot!
"Rather than wrapping it in an object, you can also reference your parent's scope directly.
I've set up an example here: http://plnkr.co/edit/aqTUSBEvbJafX0r3luXy"
Works! Thanks!
Thanks a lot.
Is there a way after you select one to have it saved to another model in the controller?
like something like this: $scope.myselect = $parent.selected
As far as i know $parent
would be related with the parent element in which our variable is. So, if we use the controller as sintax it would be linked to the this
vasriable of our controller, and if we don't use it, it would be inside the $scope
direcly.
So, $parent.radioElement
in the template would be in our controller eighter $scope.radioElement
or this.radioElement
, or myVariable.radioElement
(thinking that myvariable
is a copy or the parent of the element to which the input is binded)
@Alevale, not sure what you mean (also note that this is a very old thread you are responding to), but I just wanted to point out that $parent
always refers to Scopes (not Controllers). Even when you are using the controller as
syntax there is a scope involved. (In fact, your controller's this
is bound on the scope as the specified alias.)
what about ng-repeat on ng-repeat like below?
<li ng-repeat="quest in Questions"> {{quest.question}} <div ng-repeat="choice in quest.answer"> <input type="radio" value="{{choice.pil}}" ng-model="$parent.selected" name="stuff"> {{choice.answer}} </div> <br> </li>
in that case $parent.selected said "not defined"
@n0s13, for general support question, please, use one of the appropriate support channels.
GitHub issues are reserved for bug reports and feature requests.
@tynman thank you for the plnkr link.
Most helpful comment
Please add this to the documentation. I spent too long searching and experimenting before finding this.
Thanks!