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.