<xf:select1>
selection controls:<xf:itemset>
and <xf:item>
to define the values suggested to the user. Just as with <xf:select1>
, what is visible to users are item's labels and what is stored in the node to which your autocomplete is bound is the selected item's value.<xf:select1>
, the autocomplete only implements a closed selection: users will only be able to select a value which exists in the itemset. The value of the node bound to the autocomplete won't be set to the value typed by users in the field, unless they select an item from the suggestion list or type text which is identical to one of the item's label.<xf:submission>
, and this list can change depending on other values entered by users in other fields of the page. But at a given point in time, that list must be complete; you can't change it depending what users are currently typing in the field as they type.GET
, that, given the current value users typed in the search field, returns an XML document with the list of suggestions.ref
: binds the autocomplete to a node that will that the autocomplete will populate with the selected item's value.labelref
: binds the autocomplete to a node that will that the autocomplete will populate with the selected item's label. The XPath expression in labelref
is evaluated in the context of the node to which the control is bound to. This attribute is optional, but if you don't specify it, when loading a form where an autocomplete already has a value, then autocomplete will show empty, which most likely will be seen as incorrect behavior by users. This is because in resource mode, as well as in dynamic mode (see below), the autocomplete doesn't know about all the items, and thus can't automatically infer the label it needs to show users based on a value stored in the instance. labelref
solves this problem by also storing the label in the instance.resource
: points to an HTTP service responding with an XML document. It is interpreted as an AVT, and you can use the $fr-search-value
to refer to the value users typed so far in the search field, as done in the above example.<xf:itemset>
: points to the items in the XML returned by the service, and for each item to its label and value.resource
AVT evaluates to a different URI, a request is made by the autocomplete to that new URI to retrieve the a new itemset. Typically, your resource
AVT will use $fr-search-value
, and thus whenever users change the value in the search field, your service will be called. But this mechanism is general, and should your AVT, say, refer to a node in an instance that can change, then the service will we called again every time a change occurs.POST
rather than a GET
.)fr-search-changed
on the <fr:autocomplete>
, and run an action that updates the itemset. You are in control of where the data comes from, what subset of the data is to be displayed in the suggestion list based on what the user types, and when the suggestion is to be made.fr-search-changed
event is written is a such a way that:labelref
attribute, see the above section the resource mode.fr-search-changed
– What did the user type in the field?fr-search-changed
event to be notified when the value typed in the field changes. This event is dispatched as users type in the field, just like the xforms-value-changed
event would for an incremental <xf:input>
. The preceding example uses this event to update the itemset as users type in the field.xforms-value-changed
– When did the user make a selection?xforms-value-changed
to be notified when the value of the node bound to the autocomplete changes. That event is also dispatched when users make a selection from the suggestion list, or when they happen to have typed a value that exactly matches one of the items in the itemset. This event is dispatched when the autocomplete looses the focus. At that time, the node bound to the autocomplete is also updated with the value corresponding to the label typed or selected by users. If the label in the field doesn't correspond to label of any item in the itemset, both the value of the node bound to the autocomplete as well as the content of the search field are set to empty string.fr-set-label
event to the autocomplete component, with label
as context information. For instance:fr-search``-changed
event, upon which your code can change the itemset. If you do change the itemset, and there is a single value corresponding to the label you specified, then the node to which the autocomplete is bound is set to that value.fr-search-changed
event. If the value is set, the autocomplete can't dispatch a fr-search-changed
event, since it doesn't know the label yet, and your code won't load the appropriate itemset that contains the label for the new value. In dynamic itemset mode, always use the fr-set-label
event to indirectly set the value of the control. If you want the autocomplete to be populated based on a value in the instance when the form loads, on xforms-model-construct-done
you need to find what the label corresponding to this value is, and dispatch an fr-set-label
event with that label. As an exception to this rule, setting the value of bound node to empty string is supported in all cases: it is understood as a "reset" and will also set the search field to empty string.max-results-displayed
. You would typically use this attribute to provide a static value. For instance:<fr:max-results-displayed>
, which supports single node binding attributes (ref
, model
, and bind
) as well as the value
attribute. For instance:<fr:max-results-displayed>
element has priority over the max-results-displayed
attribute, which has priority over the global property.fr-search-changed
event with an empty label
, and in resource mode when your service is called with an empty search value.show-suggestions-button="false"
attribute on the control. The default value of this attribute is true
.140px
. You can change the width of all the autocomplete fields with:<fr:autocomplete class="my-autocomplete">
and the following CSS: