Page History
...
clear | both |
---|---|
align | right |
class | menu |
This page describes two ways in which you may define the type of a field in a form .
...
When creating a form for a dialog's tab, you usually 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 minimum – a property telling Magnolia what type of field it should render in the dialog.
...
- For the
fieldType
property you no longer need to specify the field type using a fully qualified class name. Just provide the field's name as the value of thefieldType
property.
If your project uses theclass
propertty property in too many places, you may can still continue usingclass
. The feature is backwards compatible. - We have streamlined the definition names by making them shorter. The In selected modules (see the Short field names list below on this page ), the field name does not even require the
-Field
or -FieldDefiniton
suffix. shows which fields are affected.
Applied to the above example the configuration can now be as simple as this:
...
- The origin of the definition. The fields defined previously as JCR nodes under
/modules/<module-name>/fieldTypes
folders are now defined from YAML files.
See the following example showing the definition ofdamUploadField
in Magnolia 5.6.6 and the correspondingdamUpload
definition in Magnolia 5.7:
- The file names. If a field was previously defined in a YAML file, the file's name has changed to the new short name is now used as the filename. See for example the definition of the Expandable Expanding text field:
/content-editor/fieldTypes/expandingTextField.yaml
(in Magnolia 5.6.6)/content-editor/fieldTypes/expandingText.yaml
(in Magnolia 5.7)
...