LabelFormField keine Einschränkung nach Kategorie möglich

  • Affected Version
    WoltLab Suite 5.3
    Affected App
    WoltLab Suite Core

    Hallo zusammen,


    das LabelFormField dient dazu im neuen AbstractFormBuilderForm schnell und einfach eine Labelzuweisung vornehmen zu können. Es sieht aber danach aus, als wenn nicht bedacht wurde, dass ein Label nicht Zwangsweise in allen Kategorien verfügbar sein muss. Das LabelFormField sieht keine Möglichkeit vor die angezeigten Labelgruppen bei Kategoriewechsel ein-/auszublenden.


    Dies könnte man beispielsweise einfach umsetzen, wenn man LabelFormField ein zugehöriges Kategorie-Feld zuweisen könnte. Bei Wechsel der Kategorie-ID werden Labelgruppen dann per JS ein-/ausgeblendet (ähnlich wie bei Eingabefelder). Aktuell ist das LabelFormField so nicht benutzbar, wenn man nicht viel manuellen Aufwand investiert, den man sich bei Verwendung vom AbstractFormBuilderForm ja eigentlich sparen möchte.


    Habe ich etwas übersehen oder liegt hier ein Designfehler vor?

    • Official Post

    Hallo,

    Das LabelFormField sieht keine Möglichkeit vor die angezeigten Labelgruppen bei Kategoriewechsel ein-/auszublenden.

    Ein LabelFormField zeigt jeweils die Label einer einzelnen Labelgruppe an. Wenn du mehrere Labelgruppen zur Auswahl stellen willst, dann hast du auch mehrere LabelFormFields.


    Die Verfügbarkeit einzelnen Felder kannst du auf Basis der Dependencies (in deinem Fall wohl ValueFormFieldDependency) steuern. Entsprechend müsstest du passende Dependencies zwischen dem Kategorieauswahl-Feld und den Labelgruppen-Feldern definieren. Die Label kennen das Konzept von Kategorien nicht und denen dieses Konzept beizubringen wäre eine Layering-Verletzung.

  • Tim Düsterhus

    Danke für dein Feedback. Ich habe es nun wie folgt gelöst:


    Vorher:

    Code
    $labelFields = LabelFormField::createFields(
                'de.darkwood-studios.ticketsystem.projectmanager.project',
                ProjectLabelObjectHandler::getInstance()->getLabelGroups(),
                'label');
    $fields = array_merge($fields, $labelFields);

    Nachher:

    Das funktioniert zwar, fühlt sich aber unnötig kompliziert an. Hast du hier eine einfachere Lösung im Kopf oder kannst dir vorstellen, wie es im Framework einfacher abgebildet werden kann, um boilerplate code zu reduzieren?


    Ich freue mich auf deine Antwort.

  • Viel Spaß das in der Action dann zu verarbeiten. :P

    Das funktioniert so tatsächlich schon ohne Änderungen am bisherigen Code.


    Ich kann mir aber dennoch nicht vorstellen, dass das die Lösung ist, die sich WoltLab bei der Entwicklung des LabelFormFields vorgestellt hat. Leider gibt es bei den Apps von WoltLab auch keinen einzigen Anwendungsfall. WoltLab nutzt das LabelFormField bei den eigenen Anwendungen nicht.

  • Ah, dann hattest du die Parameter wohl bisher auch schon so übergeben?


    Naja, ich mache das bei Sprachen auch so bzw. habe den i18n Redactor jetzt selbst "aktiviert", weil es mir zu blöd war und ich WoltLabs Umsetzung ehrlich gesagt mehr als (optisch) unschön finde.

    • Official Post

    Hallo,

    Das funktioniert zwar, fühlt sich aber unnötig kompliziert an. Hast du hier eine einfachere Lösung im Kopf oder kannst dir vorstellen, wie es im Framework einfacher abgebildet werden kann, um boilerplate code zu reduzieren?

    ungetestet:

    Du müsstest allerdings dann noch schauen, ob es für Probleme sorgt, wenn dieselbe Labelgruppe in mehreren Kategorien verfügbar ist, dann werden wohl mehrere Felder erstellt. Das kannst du dann aber wohl lösen, indem du alle passenden Kategorien als Array in der Dependency angibst.

  • Hallo,

    ungetestet:

    So sah mein erster Versuch auch. Dann musste ich aber feststellen, dass LabelFormField ein array von Objekten benötigt und in $__groupIDs nur die IDs drin stehen. So einfach klappt das also auch nicht.


    Hier sehe ich ganz klar Verbesserungspotential beim LabelFormField, welche fast immer in Kombination mit Kategorien genutzt werden und auch entsprechend damit umgehen sollten. - ohne ständig 20 Zeilen Code von Form zu Form kopieren zu müssen. - vielleicht kannst du das ja mal als Feedback für eine kommende Version mitnehmen.

    • Official Post

    Hallo,

    So sah mein erster Versuch auch. Dann musste ich aber feststellen, dass LabelFormField ein array von Objekten benötigt und in $__groupIDs nur die IDs drin stehen. So einfach klappt das also auch nicht.

    Der Weg von IDs zu tatsächlichen Objekten ist aber nun wirklich kein Hexenwerk mehr. Das größere Problem ist, dass du, wie schon vermutet:

    Du müsstest allerdings dann noch schauen, ob es für Probleme sorgt, wenn dieselbe Labelgruppe in mehreren Kategorien verfügbar ist, dann werden wohl mehrere Felder erstellt. Das kannst du dann aber wohl lösen, indem du alle passenden Kategorien als Array in der Dependency angibst.

    doppelte Felder erstellst.


    Ich kann dir folgendes (getestet) auf Basis der Kategorien für Artikel anbieten:


    Hier sehe ich ganz klar Verbesserungspotential beim LabelFormField, welche fast immer in Kombination mit Kategorien genutzt werden und auch entsprechend damit umgehen sollten. - ohne ständig 20 Zeilen Code von Form zu Form kopieren zu müssen. - vielleicht kannst du das ja mal als Feedback für eine kommende Version mitnehmen.

    Wie ich schon erklärt habe, ist es nicht die Aufgabe des Feldes sich um seine eigenen Abhängigkeiten zu kümmern. Die Tatsache, dass du einen Zusammenhang zwischen Kategorie-Auswahl und Labelgruppen hast, ist letztlich eine Eigenschaft deines Formulars. Nicht jede Kategorie kennt überhaupt Label (unser Blog nutzt die Funktion beispielsweise nicht) und nicht immer enthält das Erstellungs-Formular auch die Kategorie-Auswahl (beispielsweise im Forum, wo die Kategorie [1] beim Aufruf des Formulars feststeht).


    Insofern ist der Code da oben insofern „optimal“, als, dass er eine saubere separation of concerns umsetzt und die Verknüpfung der Felder an der Stelle vornimmt wo sie logisch korrekt aufgehoben ist. Nämlich in dem Formular. Ja, es entsteht ein bisschen Boilerplate-Code, aber der Control Flow ist sehr simpel und „offensichtlich“ korrekt. Die eigentliche Feld-Logik besteht aus 11 Zeilen, mit einer simplen Schleife und nur 3 Semikolons.


    [1] In diesem Fall der Forenbereich.

  • Ja, es entsteht ein bisschen Boilerplate-Code, aber der Control Flow ist sehr simpel und „offensichtlich“ korrekt. Die eigentliche Feld-Logik besteht aus 11 Zeilen, mit einer simplen Schleife und nur 3 Semikolons.

    Wobei ich das, was du da jetzt zeigst, nicht unbedingt Boilerplate-Code ist, wenn ich mir das so ansehe. Es ist ja eine gewisse Logik dahinter und es stimmt ja: Nicht jedes Formular ist gleich.


    Wenn man jetzt anfängt die Felder noch über wechsel Beziehungen zu verknüpfen, kann man irgendwann die berechtigte Frage stellen, warum ihr nur den einen Fall abdeckt, aber nicht auch andere Fälle.


    Ihr liefert die wichtigen Möglichkeiten mit, dass man mit den Abhängigkeiten weitgehend die Darstellung des Formulars steuern kann und zwar auch sehr elegant und dass man am ende alles hat.


    Aber - und das muss man dann auch sagen: Es wäre schön, wenn ihr solchen Code-Schnipsel als Beispiele mal sammelt und auch in die Dokumentation mit aufnehmt für bestimmte Probleme, so dass man nicht im WSC/WCF-Quellcode schauen muss. Das wäre dann echt top!

Participate now!

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