Package com.smartgwt.client.docs

# Interface FormItemTypeSelection

public interface FormItemTypeSelection

### FormItem classes for databound component fields

`DynamicForms` and subclasses are responsible for choosing the appropriate `FormItem` type (or subclass) for their fields. This is true for standalone instances of `DynamicForm` or `SearchForm` and embedded forms used by editable components such as the `ListGrid`.

The `DynamicForm.getEditorType()` method is responsible for determining what form item class to create for any field. This may be overridden by subclasses such as `SearchForm`, or by custom logic in dataBoundComponents with an editable view such as the ListGrid which provides `ListGrid.getEditorType()` and `ListGrid.getFilterEditorType()`.

At the component field level, the item type may be specified via an explicit `editorType` or `filterEditorType` property. For non-filter components such as standard DynamicForms or editable ListGrids, `field.editorType` may be used to specify the desired editor type for the field.
For filter components, including `SearchForm` and `ListGrid filter editors` `filterEditorType` is used. If `filterEditorType` is unset but `editorType` is set, filter components will use `editorType`.

The default formItem class can also be specified at the `DataSourceField` level or the `SimpleType` level for custom data types. See the `editorType`, `filterEditorType` and `readOnlyEditorType` attributes for those classes of objects.

If no explicit FormItem type was specified, the default formItem for a field will vary by data type and other properties. The following overview outlines most of the cases you'll encounter. This is intended as an orientation only, not a definitive list of every default FormItem-subclass for every combination of field settings.

In general, if a named "data-type item" exists it will be used by default for the data type. So fields of type `"text"` (which is also the default for fields with no explicit type) render in a `TextItem` by default, fields of type "integer" render in an `IntegerItem`, and so on. This is described in the `FormItemType` overview. However there are many exceptions to this rule of thumb.

Fields with a `valueMap` will render as a `SelectItem` in editing interfaces - `DynamicForm` or `editable ListGrid` - by default.
In filtering interfaces - `SearchForm`, `ListGrid filterEditor` - they will render as a `multi-select` for small sets of options, or the specified `DynamicForm.largeValueMapFilterEditorType` for `large sets of options`. This is the `SetFilterItem` by default, with intelligent logic in place to back off to the default SelectItem if the target dataSource does not support `"inSet"` criterion operators.

Fields which derive their options from an optionDataSource will behave like large valueMaps, rendering as a SelectItem in editing interfaces and a SetFilterItem in filtering interfaces. This includes fields with a `foreignKey relationship`, with the exception of multi-FK relationships (fields with `multiple:true` representing one-to-many relationships as described in `the relations overview`). These fields will render a `MultiPickerItem` in editing interfaces by default.

Text fields with `DataSourceField.length` greater than `DynamicForm.longTextEditorThreshold` will render in a TextAreaItem by default. See `DynamicForm.longTextEditorType`. Note that for `editable ListGrids` long text fields will render a pop-up with a text-area in it for better presentation to the user.

Fields of type `date` and `datetime` will render in editing interfaces using the DateItem and DateTimeItem by default. In filtering interfaces they will render as `DateRangeItem` in a standalone SearchForm, or `MiniDateRangeItem` within ListGrid filterEditors.

Most binary fields in DynamicForms are rendered as `FileItem` or the `FileDropZone-based` `FileUploadItem` depending on the value of `DynamicForm.useFileUploadItem`.
See the `Upload` and `BinaryFields` overviews for more information about binary fields in Smart GWT.