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.