Posts by Darkwood.Design

    Sobald ein Bild aus dem SingleMediaSelectionFormField gewählt wurde, möchte ich ein Textfeld einblenden. Dafür habe ich eine Abhängigkeit wie folgt erstellt:

    Code
    $foregroundMediaField = SingleMediaSelectionFormField::create('mediaID')
                ->imageOnly(true);
            
    $fields[] = $foregroundMediaField;
            
            $fields[] = TextFormField::create('mediaWidth')
                ->addDependency(
                    NonEmptyFormFieldDependency::create('mediaID')
                        ->field($foregroundMediaField)
                );

    Das Textfeld wird nicht mehr angezeigt - selbst wenn eine mediaID gewählt wurde.

    Hallo zusammen,


    folgendes Problem. Ich habe mit dem AbstractFormBuilderForm Kategorieabhängige Labelgruppen über das LabelFormField realisiert. Siehe RE: LabelFormField keine Einschränkung nach Kategorie möglich


    Beim Wechsel der Kategorie wechseln also auch die abhängigen Labelgruppen. Wenn vorher aber in einer anderen Labelgruppe einer anderen Kategorie ein Label gewählt wurde, wird dies einfach beim Speichern mit übergeben, obwohl das Feld nicht mehr sichtbar ist.


    Richtig wäre es, wenn Eingaben aus nicht mehr zutreffenden Abhängigkeiten zurückgesetzt werden.

    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.

    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.

    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.

    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?

    Hallo zusammen,


    beim Hinzufügen einer neuen Datei bekomme ich nach Klick des "Absenden" Buttons folgenden Fehler in der console:


    Quote

    An invalid form control with name='values[fileOption4]' is not focusable.

    Das liegt daran, dass das betroffenen Pflichtfeld in der gewählten Kategorie nicht sichtbar ist.


    Reproduzierbar:

    1. Zwei Kategorien erstellen
    2. Zwei Pflichtfelder erstellen (das erste in Kategorie 1, das zweite in Kategorie 2)
    3. Neue Datei in Kategorie 1 hinzufügen
    4. => Browser kann Pflichtfeld für Kategorie 2 nicht fokussieren (da korrekter Weise display: none;)

    Hinweis:
    Ist auch in einer frischen Installation der Filebase 5.4 reproduzierbar.


    Browser:
    Chrome Version 92.0.4515.107 (Offizieller Build) (x86_64) [macOS]

    Hallo @Kreuzhorst


    schön dich in der WoltLab-Welt begrüßen zu können.


    Natürlich solltest du nicht einfach „Apps“ installieren, damit sich dein Projekt „voller“ anfühlt. Meiner Erfahrung nach hat das eher den gegenteiligen Effekt.


    Überlege dir ein klares Konzept für dein Projekt. Was kann deine Seite besonders gut? Wieso sind die Nutzer bei dir? Und dann setze es konsequent um. Wenn du dir selbst die Frage stellen musst, ob du eine Erweiterung brauchst, dann wirst du sie aller Wahrscheinlichkeit (noch) nicht brauchen.


    Forum und Galerie sind ein toller Start für eine Foto-Community. Stelle die Galerie in den Fokus, lass die Community im Forum aufleben und beeindrucke deine Nutzer mit spannenden Fachartikeln über das Artikelsystem. Dann wird dein Projekt ein voller Erfolg. :thumbup:


    Beste Grüße und viel Spaß mit der WoltLab Suite,

    Daniel

    aber es wäre mir neu, dass die Gruppenpriorisierung in irgendeinem Zusammenhang mit dem Berechtigungssystem steht.

    Genau das ist das Problem. Wenn man die Priorisierung auch für die Berechtigungen verwenden würde, wüsste man direkt welches Recht für welchen Benutzer greift und könnte das wunderbar flexibel konfigurieren. Gerade in Communities mit knapp 100 Gruppen würde das vieles einfacher machen. (auch die Idee mit dem Vererben von Rechten)

    Anregung:


    Es gibt bereits jetzt die Möglichkeit eine Priorisierung anzugeben - darüber könnten auch die Berechtigungen ausgerechnet werden.


    Bilden wir das mal auf das oben genannte Beispiel ab:


    Priorität Gruppe Recht: Zeitraum für Beitragsbearbeitung
    1000 Administrator 0
    10 Registrierte Benutzer 120
    1 Jeder 60


    Benutzer A ist in den Gruppen "Jeder" und "Registrierte Benutzer". Da letztere die höhere Prio hat, greift dieser Wert.

    Benutzer B ist "Jeder, "Registrierte Benutzer" und "Administrator". Da Admins die höchste Prio haben, greift der Wert 0.


    Da das aber gerade bei vielen (ähnlichen) Gruppen durchaus zu Problemen bei der Konfiguration führen kann würde ich sogar noch einen Schritt weiter gehen und den Wert "AUTO" für Berechtigungen einführen. Ist dieser Wert gesetzt wird die Berechtigungen von der nächsten Gruppen geerbt.


    Ein Ja/Nein-Recht hat also künftig die Möglichkeiten JA | NEIN | AUTO


    Beispiel:


    Priorität Gruppe Recht: Darf Feature verwenden
    1000 Administrator JA
    50 Premium AUTO
    20 Sponsoren NEIN
    10 Registrierte Benutzer JA
    1 Jeder NEIN


    Benutzer A ist in den Gruppen "Jeder", "Registrierte Benutzer", "Sponsoren" und "Premium". Da das Recht in der Gruppe mit höchster Priorität auf AUTO steht, greift die Gruppe "Sponsoren" für dieses Recht. Der Benutzer hat keinen Zugriff auf dieses Feature.


    Benutzer B ist in den Gruppen "Jeder", "Registrierte Benutzer" und "Premium". Da das Recht auf AUTO steht, greift die Gruppe "Registrierte Benutzer" für dieses Recht. Der Benutzer hat Zugriff auf dieses Feature.


    Damit wäre das Gruppensystem maximal flexibel einsetzbar und dank Priorisierung ist immer klar, welche Berechtigungen der Benutzer hat.