****************
foundation-field
****************
``foundation-field`` is a vocabulary to standardize the form field.
In an application it is possible that we use many form field components from many different vendors.
For example, native HTML provides ```` while CoralUI provides ````.
Because of this, the standardization into a normalized API is good way to interact with them, such that the application code can be more independent.
To select a logical field, you can use :doc:`:-foundation-submittable <../js/validation/index>` selector.
Event
=====
foundation-field-change
-----------------------
The event that MUST be triggered when the field value is changed.
The event has the following interface:
.. code-block:: ts
interface FoundationFieldChangeEvent {
(): void;
}
AdaptTo Interface
=================
type
``foundation-field``
condition
Any field element that can be adapted to this type
returned type
``FoundationField``
.. code-block:: ts
interface FoundationField {
/**
* Returns the name that identifies the field when submitting the form.
*/
getName(): string;
/**
* Returns true if the field is disabled; false otherwise.
*/
isDisabled(): boolean;
/**
* Indicates if the field is disabled.
*/
setDisabled(disabled: boolean): void;
/**
* Returns true if the field is invalid in term of UI; false otherwise.
*
* The semantic meaning of invalid here means to indicate the field is invalid in term of UI, not necessarily implied to be due to validation.
* However if the field is invalid in term of validation, it is very likely that this method returns true.
* To check if the field is valid in term of validation, please check foundation-validation.
*/
isInvalid(): boolean;
/**
* Indicates if the field is invalid in term of UI.
*/
setInvalid(invalid: boolean): void;
/**
* Returns true if the field is mandatory to be filled; false otherwise.
*/
isRequired(): boolean;
/**
* Indicates if the field is required.
*/
setRequired(required: boolean): void;
/**
* Returns the submit value of the field.
* If the field supports multiple values, the first value is returned.
* If the field has no value, then null is returned.
*
* @see "Understanding Getting and Setting the Value" section
*/
getValue(): string;
/**
* Sets a single value to the field, such that the field changes its internal state to hold that values.
*
* @see "Understanding Getting and Setting the Value" section
*/
setValue(value: string): void;
/**
* Returns a space-separated list of element IDs used to label the field.
*/
getLabelledBy(): string;
/**
* Sets a space-separated list of element IDs used to label the field.
*/
setLabelledBy(value: string): void;
/**
* Returns the values of the field.
* If the field doesn't support multiple values, the array of the single value is returned.
* If the field has no value, then empty array is returned.
*
* @see "Understanding Getting and Setting the Value" section
*/
getValues(): string[];
/**
* Sets multiple values to the field, such that the field changes its internal state to hold that values.
*
* @see "Understanding Getting and Setting the Value" section
*/
setValues(values: string[]): void;
}
Understanding Getting and Setting the Value
===========================================
It is important to note that the "value" when using ``getValue``, ``setValue`` and their plural counterparts is meant to deal with submit value.
The submit value is not necessarily meant that the value is indicated by ``value`` attribute of an element.
This is designed this way as ``foundation-field`` is used to get or set the stored value, but not to configure the definition of the form fields themselves.
A good example for this is ````.
It has a user semantic that allow the user to check/uncheck to indicate if the value is submitted or not.
However the user doesn't change the definition value when she does that.
So in this case, calling ``FoundationField#getValue()``, it will return ``value1`` when the checkbox is checked, otherwise it is ``null``.
Contrast this when you read its native ``value`` property, you will get ``value1`` regardless of checked state.
Likewise, when calling ``FoundationField#setValue()``, it will set ``checked`` property to ``true`` only if its value matches the passed parameter, without modifying its ``value`` property.
Contrast this when you write its native ``value`` property, you will set ``value1`` regardless of checked state.
Example
=======
Given the following HTML:
.. code-block:: html
Fetching the value of each field using ``FoundationField#getValue()`` produces the following results:
* textfield returns ``textfieldOld`` string
* checkbox1 and checkbox3 returns ``null`` because they are unchecked
* checkbox2 returns ``checkbox`` string because it is checked
* select returns ``select2`` string
Setting the value of each field using ``FoundationField#setValue()`` with the following values, match by name:
.. code-block:: js
var values = {
textfield: "textfield1",
checkbox1: "checkbox",
checkbox2: "othervalue",
checkbox3: ["othervalue", "checkbox"]
select: "select3"
};
produces the following results:
* textfield has value of ``textfield1``
* checkbox1 and checkbox3 are checked, due to the matching value
* checkbox2 is not checked, due to non matching value
* ``Select 3`` option is selected, while other options are not