Multiple inputs with the same name bug

[slavafomin]

When you have multiple input fields with the same name, like radio buttons for example, you are getting one ngModel controller for each input. But, when you addressing this field by name, like this: formName.fieldName, you are getting a reference to the last ngModel controller.

The problem is that this controllers doesn't know about each other and do not coordinate their state. And from the user perspective they must have a shared state.

>> The bug is illustrated here <<

In the provided example, I'm trying to detect pristine state of the gender radio field, but I'm getting incorrect result, since I'm getting pristine state not of the entire radio group but only of the last radio button in the group.

From the end-user perspective this can be considered a real bug.

As a solution to this problem, maybe we should use a single ngModel controller for all inputs with the same name, or probably better, to synchronize the state of ngModels from the same group, so properties like $pristine would be consistent.

[caitp]

Related to #3345 --- I'm not sure I completely buy @pkozlowski-opensource's suggestion to not use the same name, because this is actually how browsers kind of need to work, in order to select the right control --- it works in angular, but it's a huge hack, and we shouldn't need to instantiate multiple ngModels which need to be shared anyways.

This probably should be fixed, but it might need to wait for @matsko's refactoring

(but, in case this won't be fixed, you can use the workaround which requires you to specify different names, but the same ng-model value, for each input --- and not have $pristine be represented consistently for each one)

[slavafomin]

Maybe the better idea is to create a shared controller for all inputs within a single group. This way we will be able to check state of the concrete input or of the entire group, like this:

formName.fieldName.$pristine // Concrete input element flag
formName.fieldName.$group.$pristine // Flag for all the inputs inside of a group (if one input is not pristine, then the group is not pristine also)

[shahata]

Also, @pkozlowski-opensource's solution will not work properly if ngModelOptions is used in order to pend model updates (you will actually see two checked radio buttons until the model value gets committed)

[slavafomin]

I've created a very simple module to demonstrate my latest idea (stated in my previous comment).

Here's the CODE for it. And here's the updated DEMO that is using this module.

[petebacondarwin]

Do you know what? I think what we need to do is implement a ngRadioGroup directive. The problem is that ngModel is supposed to map one-to-one with a form field but that radio buttons don't constitute a single field in a form but part of a field. A single radio button on its own has no real meaning.

Let's implement ngRadioGroup for 1.5 - any thoughts?

[Narretz]

I'm not a big fan of radioGroup directives or contructs in general, because they don't go along well with how HTML works. Coul we cook up something that does the grouping internally? Or exposes an extra radioGroup controller?