Configuration 

A lot of configuration. Why? 

Building forms in a declarative and programmatic way is complex. Dynamic forms need program code that is as generic as possible. But generic program code means a lot of configurative overhead.

Having so much configuration may seem overwhelming, but it has a lot of advantages. Many aspects of EXT:form can be manipulated purely by configuration and without having to involve a developer.

The configuration in EXT:form is mainly located in places which make sense to a user. However, this means that certain settings have to be defined in multiple places in order to avoid unpredictable behaviour. There is no magic in the form framework - it is all about configuration.

Why YAML? 

Previous versions of EXT:form used a subset of TypoScript to describe form definitions and form element behavior. This led to a lot of confusion among integrators because the definition language looked like TypoScript but did not behave like TypoScript.

Form and form element definitions had to be declarative, so YAML was chosen as it is a declarative language.

YAML registration 

YAML configuration files are discovered automatically — no PHP or TypoScript registration is required.

Place your YAML files in EXT:my_extension/Configuration/Form/<SetName>/ and add a config.yaml with a unique set name. TYPO3 scans all active extensions and loads the files automatically for both frontend and backend.

EXT:my_extension/
  Configuration/
    Form/
      MyFormSet/
        config.yaml

name: my-vendor/my-form-set
label: 'My Custom Form Set'
# Load order: lower = loaded first. Core base set uses priority 10.
# Extension sets should use > 10 (default: 100) to overlay the base.
priority: 200

# Form configuration goes directly below the metadata:
persistenceManager:
  allowedExtensionPaths:
    10: 'EXT:my_extension/Resources/Private/Forms/'

YAML loading 

TYPO3 uses a 'YAML loader' for handling YAML, based on the Symfony YAML package. This YAML loader is able to resolve environment variables. In addition, EXT:form comes with its own YAML loader, but it has some restrictions, especially when resolving environment variables. This is for security reasons.

EXT:form differentiates between form configuration and form definition. A form definition can be stored in the file system (FAL) or can be shipped with an extension. The type of YAML loader used depends on the setup.

Configuration aspects 

Four things can be configured in EXT:form:

• frontend rendering,
• the form editor,
• the form manager, and
• the form plugin.

All configuration is placed in a single config.yaml per form set and is loaded for both frontend and backend. It is up to you whether you want to keep all configuration in one set or spread it across multiple form sets with different priorities.

Inheritance 

The final YAML configuration does not produce one huge file. Instead, it is a sequential compilation process:

• Registered configuration files are parsed as YAML and are combined according to their order.
• The __inheritances operator is applied. It is a unique operator introduced by the form framework.
• Finally, all configuration entries with a value of null are deleted.

Instead of inheritance, you can also extend/override the frontend configuration using TypoScript:

plugin.tx_form {
    settings {
        yamlSettingsOverrides {
            ...
        }
    }
}

An example of overriding the EXT:form Fluid templates. Place the configuration in EXT:my_site_package/Configuration/Form/SitePackage/config.yaml (auto-discovered, no PHP or TypoScript registration required):

prototypes:
  standard:
    formElementsDefinition:
      Form:
        renderingOptions:
          templateRootPaths:
            20: 'EXT:my_site_package/Resources/Private/Templates/Form/Frontend/'
          partialRootPaths:
            20: 'EXT:my_site_package/Resources/Private/Partials/Form/Frontend/'
          layoutRootPaths:
            20: 'EXT:my_site_package/Resources/Private/Layouts/Form/Frontend/'

The values in your own configuration file will be merged on top of the EXT:form base set (EXT:form/Configuration/Form/Base/config.yaml).

customEditor: &customEditor
  1761226183:
    identifier: custom
    templateName: Inspector-TextEditor
    label: Custom editor
    propertyPath: custom

otherCustomEditor: &otherCustomEditor
  identifier: otherCustom
  templateName: Inspector-TextEditor
  label: Other custom editor
  propertyPath: otherCustom

prototypes:
  standard:
    formElementsDefinition:
      Text:
        formEditor:
          editors:
            <<: *customEditor
            1761226184: *otherCustomEditor

Form:
  part01:
    key01: value
    key02:
      key03: value
  part02:
    __inheritances:
      10: Form.part01

Form:
  part01:
    key01: value
    key02:
      key03: value
  part02:
    key01: value
    key02:
      key03: value

Form:
  part01:
    key: value
  part02:
    __inheritances:
      10: Form.part01
    key: 'value override'

Form:
  part01:
    key: value
  part02:
    key: 'value override'

Prototypes 

Most of the form framework configuration is defined in prototypes. standard is the default prototype in EXT:form. Prototypes contain form element definitions - including frontend rendering, form editor and form plugin. When you create a new form, your form definition references a prototype configuration.

This allows you to do a lot of clever stuff. For example:

• depending on which prototype is referenced, the same form can load different

  • ...templates
  • ...form editor configurations
  • ...form plugin finisher overrides

• in the form manager, depending on the selected prototype

  • ...different form editor configurations can be loaded
  • ...different pre-configured form templates (boilerplates) can be chosen
• prototypes can define different/ extended form elements and display them in the frontend/ form editor

The following use case illustrates the prototype concept. Imagine that two prototypes are defined: "noob" and "poweruser".