Referencing fields - 5 UI
Deprecated
|
This way of referencing fields has been deprecated since Magnolia 6.0. It is part of the Magnolia 5 UI framework. For the updated implementation, see the |
This page describes how to define the type of a field in a form, using one of the following:
-
fieldTypeproperty. -
classproperty (used until Magnolia 5.7).
When creating a form for a dialog tab, you typically want it to contain some fields. The fields are the core building blocks of the form’s functionality for user tasks such as entering a text and sending it to a server after the user hits the form’s submit button.
Fields are defined using a field definition, which must contain at least one property telling Magnolia what type of field it should render in the dialog.
Using the fieldType property and short field names
Use the fieldType property for better legibility, ease of development,
and to make field names easier to remember. Provide the field’s name as
the value of the fieldType property. Refer to the
Short field names table for a list of field
names. You do not need to specify the field type using a fully qualified
class name.
An example of configuration using the short fieldType property:
form:
tabs:
- name: tabText
fields:
- name: title
fieldType: textTo check you are using the correct short field names, look at the Definitions app:
Relevance for custom fields extending or decorating Magnolia fields
Short field naming affects:
-
The origin of the definition. The fields are defined from YAML files. (They were previously JCR nodes under
/modules/<module-name>/fieldTypesfolders.)
Example showing thedamUploadYAML definition:
-
The file names. If a field was previously defined in a YAML file, the file’s name has changed to the new short name. For example, the definition of the Expanding text field is:
/content-editor/fieldTypes/expandingText.yaml.
(Was previously/content-editor/fieldTypes/expandingTextField.yaml.)
|
If you have custom fields which reuse an existing Magnolia configuration via YAML include, YAML inherit, JCR extends or by decoration, your custom definition may be broken if you reference a field which has changed its name. |
Field names shortening - 5 UI
Old name (Magnolia pre-5.7)
New name
UI module
basicTextCodeField
| Removed, previously deprecated. |
basicUploadField
checkBoxField
compositeField
dateField
hiddenField
linkField
linkFieldSelect
linkFieldSelection
multiField
nodeTypeField
nodeTypeSelect
optionsField
passwordField
selectField
staticField
switchableField
textArea
textField
twinColSelectField
workbenchField
workbench
DAM module
damUploadField
damWorkbenchField
damWorkbench
Content tags module
tagField
tag
taggingAwareDependenciesField
taggingAwareDependencies
Content dependencies module
referenceField
dependencies
Content editor module
articleBlockPicker
blockPicker
collapsibleCompositeField
expandingLinkField
expandingLink
expandingTextField
peekField
peek
refreshableTextField
refreshableText
Using the class property
Until Magnolia 5.7, the only way to specify the type of a field was to
state its fully qualified class name. For example, to create a simple
text
field named title in a dialog’s tab called tabText, you had to
create the following configuration:
form:
tabs:
- name: tabText
fields:
- name: title
class: info.magnolia.ui.form.field.definition.TextFieldDefinition
If your project uses the older class property in many
places, you can continue to use the class. The feature is backward
compatible. The Short field names list shows
which fields are affected.
|