Formular-Modifier (Data/Meta Modifiers) für dynamisches Verhalten
Formular-Modifier (Data/Meta Modifiers) für dynamisches Verhalten
~9 Min. Lesezeit Zuletzt aktualisiert am 9. August 2026
Bisher wurde jedes Feld und jeder Wert direkt in form.xml oder im DataProvider deklariert. Sobald Formularverhalten von Bedingungen abhängt - berechnete Standardwerte, dynamisch ein-/ausgeblendete Felder, abgeleitete Labels -, reicht deklaratives XML nicht mehr aus. Genau dafür gibt es Modifier.
ModifierInterface und seine zwei Methoden
Ein Modifier implementiert \Magento\Ui\DataProvider\Modifier\ModifierInterface mit genau zwei Methoden: modifyData() verändert die geladenen Werte, modifyMeta() verändert die Struktur/Konfiguration (Sichtbarkeit, Labels, Pflichtfeld-Status) der Formularfelder.
<?php
declare(strict_types=1);
namespace Mironsoft\Announcement\Ui\DataProvider\Form\Modifier;
use Magento\Ui\DataProvider\Modifier\ModifierInterface;
/**
* Fills in a placeholder title for newly created announcements.
*/
class DefaultTitle implements ModifierInterface
{
/**
* Sets a default title when no record has been loaded yet.
*
* @param array<string, mixed> $data Loaded form data, keyed by entity ID.
* @return array<string, mixed>
*/
public function modifyData(array $data): array
{
if (empty($data)) {
$data['new'] = ['title' => __('New Announcement')->render()];
}
return $data;
}
/**
* Leaves the field structure unchanged.
*
* @param array<string, mixed> $meta Current UI Component meta configuration.
* @return array<string, mixed>
*/
public function modifyMeta(array $meta): array
{
return $meta;
}
}Modifier per di.xml registrieren
Ein Modifier wird nicht direkt in form.xml referenziert, sondern über einen virtualType in die Modifier\Pool-Kette eingehängt, die der DataProvider im Hintergrund nutzt:
<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
<virtualType name="Mironsoft\Announcement\Ui\DataProvider\Form\AnnouncementDataProvider"
type="Magento\Ui\DataProvider\ModifierPoolDataProvider">
<arguments>
<argument name="pool" xsi:type="object">AnnouncementFormModifierPool</argument>
</arguments>
</virtualType>
<virtualType name="AnnouncementFormModifierPool" type="Magento\Ui\DataProvider\Modifier\Pool">
<arguments>
<argument name="modifiers" xsi:type="array">
<item name="default_title" xsi:type="array">
<item name="class" xsi:type="string">Mironsoft\Announcement\Ui\DataProvider\Form\Modifier\DefaultTitle</item>
<item name="sortOrder" xsi:type="number">10</item>
</item>
</argument>
</arguments>
</virtualType>
</config>Wichtig: Hier wird nicht die konkrete DataProvider-Klasse aus Kapitel 9 direkt erweitert, sondern über einen gleichnamigen virtualType "überschrieben" - dieser nutzt intern ModifierPoolDataProvider, die die eigene DataProvider-Klasse durch eine Pool-fähige Variante ersetzt.
Meta-Modifikation: Feld dynamisch verstecken
modifyMeta() arbeitet mit einer verschachtelten Array-Struktur, die exakt der XML-Baumstruktur aus form.xml entspricht - fieldset/general/children/title/arguments/data/config zum Beispiel entspricht dem <field name="title">-Element im general-Fieldset:
public function modifyMeta(array $meta): array
{
$meta['general']['children']['title']['arguments']['data']['config']['visible'] = false;
return $meta;
}Achtung: Diese direkte Array-Manipulation ist fehleranfällig - ein falsch geschriebener Schlüssel wirft keinen Fehler, sondern wird einfach ignoriert, und das Feld bleibt sichtbar. Kapitel 21 zeigt einen saubereren, deklarativen Ansatz über imports/exports für die häufigsten Fälle von abhängigen Feldern.
Warum Modifier - und nicht eine ViewModel-Klasse
Modifier sind ein weiteres Beispiel für Kapitel 1s ehrlichen Hinweis: Das UI-Components-Framework ruft Modifier\Pool zu einem festen Zeitpunkt im DataProvider-Lebenszyklus auf und erwartet exakt ModifierInterface als Vertrag - ein ArgumentInterface-ViewModel lässt sich hier nicht einhängen. Die injizierbare Zusatzlogik (zum Beispiel eine Regel, wann ein Feld sichtbar sein soll) bleibt trotzdem sinnvoll in ein eigenes Service-Objekt ausgelagert, das der Modifier im Konstruktor injiziert - der Modifier selbst bleibt so ein dünner Adapter.