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 $type property in Field definition for Magnolia 6 UI instead.

This page describes how to define the type of a field in a form, using one of the following:

  • fieldType property.

  • class property (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: text

To check you are using the correct short field names, look at the Definitions app:

image

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>/fieldTypes folders.)
    Example showing the damUpload YAML definition:
    image

  • 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.
Feedback