Auto-generate IDs for labels, and add for attribute

[srsgores]

We need the for attribute on every label, corresponding to the id of the input element.

Not observable on the dummy app, and should be there.

[Emerson]

Agreed, I'll look at this tomorrow!

[Emerson]

Any thoughts on what the API for this should look like? As it stands the signature for an fm-field is like:

{{fm-field label='First Name' value=model.firstName errors=model.errors.firstName}}

It would be nice to avoid a situation where the user needs to manually provide an id/for attribute. I was thinking that we could use the label text (with invalid characters removed) by default, but still allow users to pass in an id attribute that would override the default.

Does that sound reasonable?

[srsgores]

@Emerson, if the generated label is the dasherized form (first-name in this case), then yes.

But that brings me to another problem #8, and problems with the API in general. I would prefer a more "magic" API, wherein no type is required, and can be derived by the modelType or the DS.attr() call in the model. Perhaps this is already the case (have not had the chance to verify). If this is the case, then I would like something like this:

{{fm-field value=firstName}}

Currently, my needs are such that I would expect to be able to customize the output to be something like this:

<section class="form-field">
    <div class="form-label">
        <label for="first-name" class="form-field-label">First Name</label>
    </div>
    <div class="form-controls>
        <input type="text" id="first-name" placeholder="First Name" autofocus required />
    </div>
</section>

Notice how autofocus and required are specified based on the model declaration. I would expect to be do something along the lines of ember validations, where the validation can be specified on each model.

[Emerson]

Hmmm, I can see definitely see the use case here. Let me address the id/for issue to start and we can think through the other request in a separate issue. I like the idea, but want to make sure it's implemented in a flexible, sustainable way :-)

[Emerson]

@srsgores - opened issue #13 to deal with the other issues. Let me know if there are problems with this implementation (for example, can ID attributes have upper case characters)