FormBuilder Dependencies: ODER

1st Official Post
    App
    WoltLab Suite Core

    Es wäre gut, wenn man Dependencies mit or verknüpfen könnte und nicht nur explizit mit and.

    Feld 1: Kunde

    Feld 2: Adresse

    Feld 3: Freitext neue Adresse

    Feld 3 soll angezeigt werden, wenn es ein Neukunde ist oder für den Kunden keine Adresse in Feld 2 zur Verfügung steht oder keine Adresse ausgewählt wurde. Feld 2 ist nur verfügbar, wenn Feld 1 gefüllt ist.

    Feld 2 auf nicht leer zu prüfen, gibt not met zurück, wenn kein Kunde gewählt wurde, da Feld 2 an sich nicht verfügbar ist, was an sich ein korrektes Verhalten darstellt.

    • Official Post

    Hallo,

    nur als Gedanke, den du vielleicht ausprobieren könntest (und dann ggf. als PR einreichst): Schau mal ob du eine Art „Meta-Dependency“ erstellen kannst. Gedacht hatte ich an folgendes:

    Code
    ->addDependency(
    OrDependency::create('someId')
        ->subDependencies([
            NonEmptyFormFieldDependency::create('foo')->fieldId('foo'),
            NonEmptyFormFieldDependency::create('bar')->fieldId('bar'),
        ])
);

    Im PHP sollte das recht simpel umzusetzen sein. Wie gut sich das mit dem JavaScript verheiraten lässt, müsstest du mal prüfen.

    Das hatte ich vorhin versucht, hängt aber schon mal daran, dass überall IFormFieldDependency verwendet wird, was zu Funktionen zwingt, die dann effektiv nicht nutzbar sind. Wie sich das bezüglich der Prüfung im Java/TypeScript verhält, habe ich nicht groß angesehen nachdem ich dafür ziemlich wursten müsste an Stellen, an die ich innerhalb von WSC 5.4 nicht rankommen werde. Ich werde mir das nach meinem Workaround aber für WSC 5.5 oder 6.0 mal näher ansehen.

    Aktuell schreibe ich eine eigene Dependency, die das für diesen Anwendungsfall intern mit oder verknüpft.

    • Official Post

    Hallo,

    Quote from MysteryCode

    Das hatte ich vorhin versucht, hängt aber schon mal daran, dass überall IFormFieldDependency verwendet wird, was zu Funktionen zwingt, die dann effektiv nicht nutzbar sind.

    Vermutlich genau das gleiche Problem wie bei den statischen Methoden in den Interfaces und dem Decorator. Die Interfaces vom FormBuilder sind bisweilen ein wenig überspezifisch. Wenn man einzelne Methoden sinnvoll entfernen kann (etwa weil sich innerhalb des PHPs niemand darauf verlässt), dann können wir das für 5.5 gerne tun. Alternativ kann man Interface ggf. in zwei Interfaces aufteilen, die dann beide von der abstrakten Klasse implementiert werden, das sollte in Bezug auf die Kompatibilität dann auch funktionieren.

    Quote from Tim Düsterhus

    Alternativ kann man Interface ggf. in zwei Interfaces aufteilen, die dann beide von der abstrakten Klasse implementiert werden, das sollte in Bezug auf die Kompatibilität dann auch funktionieren.

    Das wäre der Ansatz, den ich mir zunächst näher ansehen will, ja. Genauso wie zu Prüfen, inwiefern ein Interface für Container Sinn macht, bzw. ob dann das allgemeine genutzt wird oder whatever.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login