Reapplying the "works with inputs without the form-control class", but in a working fashion

[smebberson]

I had a look at the code added and then later reverted that allows this directive to "work with inputs without the form-control class". The code was fine but the query selector was a little too specific.

I made a fork of your repo, git cherry-picked e93c512acc619c179d191ae6692a17c6bcef50c5 and then made some amendments so that it works on a broader range of form inputs (including select).

Would you consider using this code and reapplying the commit that was later reverted? I don't mind if you use this PR or not, but I would love for that code to make its way back into MASTER.

Let me know what you think.

[zakhenry]

Hi @smebberson , this approach is an improvement, as it will work with more inputs, but is still sub optimal, as it won't work with any custom directives that act as inputs (have validators and attach to the form by name).

My recommendation would be to have a method on the provider to specify a selector. It should default to .form-control[name] per bootstraps convention, but allow the developer to define their own convention on config.

[smebberson]

@xiphiaz, that's a fantastic idea! I'll see if I can find the time to squeeze it in. I'm don't use coffeescript that regularly either, but I'll see how I go.

[egorovpavel]

it also may be simplified to *[name] (#44 ) without breaking

[chrisfosterelli]

I think simplifying makes more sense because it adds support for radio buttons

[chrisfosterelli]

If anyone's interested (since it seems like this repo doesn't get much attention), @dgsmith2 appears to have implemented a generic selector that works with selects and radios here: https://github.com/dgsmith2/angular-bootstrap-show-errors

[axos88]

don't leave out the .form-control[name], because there may be other inputs (custom elements) that behave like form controls that you are missing now.