Bootstrap.Forms.Field insists on humanising labels that don't need to be humanised

[danpl]

Currently if I assign human-readable text to the label property of a Bootstrap.Forms.Field-derived control, it insists on dicking around with it via the human() function.

And by "dicking around", I mean this:

    // Underscore string
    value = Ember.String.decamelize(value);
    // Replace all _ with spaces
    value = value.replace(/_/g, " ");
    // Capitalize the first letter of every word
    value = value.replace(/(^|\s)([a-z])/g, function(m,p1,p2){ return p1+p2.toUpperCase(); });
    return value;

In my copy of ember-bootstrap, I just commented the call to human() out, but it would make sense to add some sort of additional property that would prevent human() from being called -- or to make that the default behaviour.

[dmathieu]

Could you give us an example of handlebars code which does not behaves as expected ?

[danpl]

Something like this:

{{view Bootstrap.Forms.TextField valueBinding="baz" label="Name of an animal"}}

-- results in a label of "Name Of An Animal", which aside from looking rather ugly, violates all sorts of grammar rules.

[dmathieu]

Yes, this is a bug.
The label should be humanized only if none has been provided and we take it automatically from the value's name.

If you want to work on a pull request, feel free to do so (=> remove the humanize if the label is provided in the tag, but not if it's determined automatically).
Otherwise, I'll look into this in a few days.

[danpl]

At the moment, I've just commented out the call to human(), but I've forked the repo, and if I have some time tomorrow, I'll have a go at it.

[danpl]

Had a few spare moments, did a pull request (separate issue, haven't figured out how to link pull requests to an existing issue yet!).

[danpl]

OK, used the labelCache prop this time, and updated the tests so that they test for correct behaviour.

[dmathieu]

Awesome ! If you open a pull request with this commit, I merge it this morning :)

[dmathieu]

Fixed with PR #60. Thanks @danpl