Add interpolation to form id/name

[ProLoser]

If this was implemented in the core, we'd finally be able to create the ui-input directive we've wanted for years. It would also enable us to add validation to inputs inside ng-repeat (currently impossible).

• Allow interpolation in name property: <input name="parent.child['{{grandchild}}']">
• Allow interpolation in the id property: <input id="parent.child['{{grandchild}}']">

What's ui-input?

The @angular-ui team has tried tackling the complexity of form generation for a while now:

• https://github.com/angular-ui/ui-input
• New ui-input directive angular-ui/angular-ui-OLDREPO#189
• https://groups.google.com/forum/?fromgroups=#!topic/angular-ui/cQN26-5nuGU
• Initial version of the ui-input directive - RFC angular-ui/angular-ui-OLDREPO#191
• http://plnkr.co/edit/3zMsNnpNfOFwExSqLj2I?p=preview

Example:

<script type="text/ng-template" id="vert-form">
  <div class="form-group" ng-class="{error:$input.error}">
    <ng-switch on="$input.type">
      <textarea ng-switch-when="textarea" name="{{$input.name}}"></textarea>
      ...
    </ng-switch>

    <div class="help" ng-repeat="(errorName, error) in $input.$errors" ng-switch="errorName">
      <span ng-switch-when="required">The {{$input.name}} field cannot be left empty</span>
      ...
    </div>
  </div>
</script>

<form name="vert-form">
<!-- or <div ng-form="vert-form"> -->
  <ui-input type="textarea" ng-model="data.item" required max-length="3"  />
  <!-- or <ui-input template="vert-form" ...> to override/specify on a field-by-field basis -->
</form>

Explanation

You create a powerful form-field template that handles all the different input types; generating labels, ids, names, <label for>, formatting, assorted error messages keyed by validation rule, and so forth. Error messages are defined for an entire form or app instead of each input.
The type property was used to select which chunk of the template you were leveraging.
The ng-model is expanded into IDs, names, and for-properties (name-spaced by the <form> or ng-form).
The $input is a scope utility to access things such as formName.inputName.$error more easily, but also provides access to transcluded properties of the <ui-input> and generated properties to make things easier like $input.id or $input.name which could of course be explicitly overwritten on the ui-input tag.

[caitp]

There are PRs implementing this already, and in mine I've shown workarounds which could be used in versions of angular prior to either one being merged. #4791 and #5231, with a demo correcting this behaviour without these patches applied in http://plnkr.co/edit/hSMzWC

[IgorMinar]

@ProLoser so you really just want:

• Allow interpolation in name property: <input name="parent.child['{{grandchild}}']">
• Allow interpolation in the id property: <input id="parent.child['{{grandchild}}']">

all the other text is just background information?

[IgorMinar]

@matsko this might be relevant to your forms work..

[matsko]

@IgorMinar not directly no. Right now I'm more set on making the error message handling better and less verbose. This solution is a great idea, but it would mess up the scoping of the input properties on the form object (they would only be available once the expression evaluates to something).

The more I think about it, the less I feel we should split the name + model properties for the input item. So instead of having <input ng-model="myField" name="myField" /> be split as $scope.myForm.field and $scope.myField, we should just place the element on the ngModel value as $input (so $scope.myField.$field). That way we don't have to watch anything (why would a model change?).

[ProLoser]

@IgorMinar yes, sorry for the extra info, I brought it up after seeing @matsko and related discussions and felt this is relevant. @matsko I believe a solution to verbosity in validation can be solved with our approach, but I don't disagree that adding the metadata to the model directly might not be a bad idea either.

I DO however understand that by using names, you can have multiple inputs throughout the application that are all tied to the same model leverage unique validation (not that I really know why you would want this). In addition, namespacing by a 'form' allows you to consider a collection of inputs completed.

Perhaps, the key is to add meta information to models as you suggest, but still allow people to use the form to check the state of a group of inputs.

Possible negative edge-case:

What if 2 inputs on the page are the same model, and both have validation messages, but you're only editing one of them, and don't want the messages to show up in both places? (such as a login or registration form in the corner when you're on the login/registration page).

[ProLoser]

@matsko et al: I'd be interested in discussing the problem at the conference if you're going to be there?

[matsko]

You're raising some excellent points. Yes I'll be at ngConf this week. Let's discuss more in person.

[ProLoser]

One thing we tried to keep in mind / address is that the issue / tedium isn't JUST error messages. It's every aspect of forms. So we addressed them all together.

[ashaffer]

Huge +1 from me on this. It would be really nice to be able to validate variable numbers of inputs for certain applications (e.g. poll creation). I was thinking that another approach to handle this could be placing each instance of the ng-repeat in a nested form, e.g.

<form>
  <input ng-model='pollTitle'>
  <ng-form name='questionList' ng-repeat='question in questions'>
     <input ng-model='questionText'>
  </ng-form>
</form>

This would produce a form that looks like:

{
  pollTitle: <text>
  questionList: [
    {questionText: <text>}
    ...
  ]
}

This might simplify some of the issues involved, allow for greater flexibility/modularity (e.g. repeating of groups of many inputs, easy ability to mixin sub-templates from other places) and eliminate the need for name interpolation.

[just-boris]

While this feature is not ready, code from the answer on stackoverlow can be used to get dynamic name of form control

[matsko]

I would really like to implement this using the same approach that Dart uses. By treating multiple instances of ngForm that have the same name as a collection. Basically, to make things backwards-compatible, we would add an forms value to the end of the ngForm instances.

This way you can read the form details like so:

myForm.forms.questionList // [ ... ] an array of ngForm items

[Narretz]

interpolation of form / input name is supported since 729c238
Can this be closed then?