Abhängige/dynamisch sichtbare Felder je nach Auswahl (Modifier-Vertiefung)
Abhängige/dynamisch sichtbare Felder je nach Auswahl (Modifier-Vertiefung)
~9 Min. Lesezeit Zuletzt aktualisiert am 9. August 2026
Kapitel 13 hat modifyMeta() als direkten, aber fehleranfälligen Weg gezeigt, Feld-Konfiguration zu ändern. Für den häufigsten Fall - ein Feld abhängig vom Wert eines anderen Feldes ein-/ausblenden - gibt es einen saubereren, rein deklarativen Mechanismus: imports/exports.
Praxisfall: Firmenfeld nur bei "B2B-Kunde"
Angenommen, das Testimonial-Formular bekommt ein neues Boolean-Feld is_business_customer - das company-Feld soll nur sichtbar sein, wenn dieses Häkchen aktiv ist. Rein deklarativ über switcherConfig:
<field name="is_business_customer" formElement="checkbox">
<settings>
<valueMap>
<map name="false" xsi:type="number">0</map>
<map name="true" xsi:type="number">1</map>
</valueMap>
<dataType>boolean</dataType>
<label translate="true">Business Customer</label>
</settings>
<formElements>
<checkbox>
<settings>
<switcherConfig>
<rules>
<rule name="0">
<value>0</value>
<actions>
<action name="0">
<target>mironsoft_testimonial_form.mironsoft_testimonial_form.general.company</target>
<callback>hide</callback>
</action>
</actions>
</rule>
<rule name="1">
<value>1</value>
<actions>
<action name="0">
<target>mironsoft_testimonial_form.mironsoft_testimonial_form.general.company</target>
<callback>show</callback>
</action>
</actions>
</rule>
</rules>
<enabled>true</enabled>
</switcherConfig>
</settings>
</checkbox>
</formElements>
</field>switcherConfig reagiert direkt im Browser auf Wertänderungen, ganz ohne Server-Roundtrip - der target-Pfad entspricht wieder der vollen Namespace-Kette aus form.xml (namespace.provider.fieldset.feldname).
Wann modifyMeta() trotzdem nötig ist
switcherConfig deckt rein clientseitige, wertbasierte Umschaltung ab. Sobald die Sichtbarkeit von Serverzustand abhängt - etwa "Firmenfeld nur bei bereits gespeicherten Kundenstimmen mit Firmenbezug anzeigen, nicht bei neuen" -, muss der Modifier aus Kapitel 13 ran, weil nur PHP zum Ladezeitpunkt weiß, ob ein Datensatz existiert:
public function modifyMeta(array $meta): array
{
$isNewRecord = $this->request->getParam('id') === null;
$meta['general']['children']['company']['arguments']['data']['config']['visible']
= !$isNewRecord;
return $meta;
}imports/exports für Datenfluss zwischen Feldern
Neben Sichtbarkeit lässt sich mit imports/exports auch reiner Datenfluss zwischen Feldern deklarieren - zum Beispiel ein Label, das sich live an den eingegebenen Kundennamen anpasst:
<field name="testimonial_text" formElement="textarea">
<settings>
<imports>
<link name="label">${ $.provider }:data.customer_name</link>
</imports>
<dataType>text</dataType>
<label translate="true">Testimonial Text</label>
</settings>
</field>Tipp: Faustregel für diese Serie: switcherConfig/imports/exports zuerst probieren, wenn es rein um clientseitige, wertbasierte Reaktionen geht - erst wenn Serverzustand (geladene Daten, Berechtigungen, Datenbankabfragen) die Entscheidung beeinflusst, zum Modifier aus Kapitel 13 wechseln. Die deklarative Lösung ist robuster gegenüber Tippfehlern, weil fehlerhafte Pfade zumindest in der Browser-Konsole auffallen, statt lautlos ignoriert zu werden.