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:

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:
  • 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 includeYAML inheritJCR extends or by decoration, your custom definition may be broken if you reference a field which has changed its name.

Short field names

Old name (Magnolia pre-5.7)New name
UI module

basicTextCodeField

(warning) Removed, previously deprecated.

code
basicUploadFieldbasicUpload
checkBoxFieldcheckbox
compositeFieldcomposite
dateFielddate
hiddenFieldhidden
linkFieldlink
linkFieldSelectlinkFieldSelection
multiFieldmultiValue
nodeTypeFieldnodeTypeSelect
optionsFieldoptionGroup
passwordFieldpassword
selectFieldselect
staticFieldstatic
switchableFieldswitchable
textArearichText
textFieldtext
twinColSelectFieldtwinColSelect
workbenchFieldworkbench
DAM module
damUploadFielddamUpload
damWorkbenchFielddamWorkbench
Content tags module
tagFieldtag
taggingAwareDependenciesFieldtaggingAwareDependencies
Content dependencies module
referenceFielddependencies
Content editor module
articleBlockPickerblockPicker
collapsibleCompositeFieldcollapsibleComposite
expandingLinkFieldexpandingLink
expandingTextFieldexpandingText
peekFieldpeek
refreshableTextFieldrefreshableText

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

(warning) 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.

#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))