Gridblock + mForm => Checkbox DefaultValue funktioniert nicht

[dpf-dd]

Moin Falko,

habe soeben folgendes Problem festgestellt:

$mform = MForm::factory();

$form->addCheckboxField("1.0.blablubb");
$form->setOptions([1 => 1]);
$form->setAttributes(['label' => 'Bla Blubb', 'default-value' => '1']);

echo $form->show();

Dieser Modul-Input OHNE Gridblock verwendet => Checkbox wird angehakt. Nutze ich das Modul INNERHALB Gridblock => Checkbox wird NICHT angehakt. Irgendeine Idee woran das liegen könnte?

Gruß, Stefan

[iceman-fx]

Nicht wirklich, da es eine MForm-interne Umsetzung des DefaultValues ist. Kommen denn irgendwelche JS-Fehler ?

[dpf-dd]

Also ich habe zwar ein paar Zeilen in der Konsole drin stehen, aber das ist "normal" glaube ich und hat nix mit dem Problem zu tun...

Die Frage ist halt, warum das ohne Gridblock funktioniert, aber sobald ich das Modul im Gridblock-Wrapper benutze eben nicht mehr. Hab mir den Gridblock-Code mal angeschaut und im Endeffekt "streamst" du ja auch nur den Output und verwendest ihn weiter - ich sehe da auch nicht wirklich wieso da mForm plötzlich den default-value "verschluckt". Der Witz ist: Ich kann dem Formular über ->setAttributes alles mögliche an Attributen+Value mitgeben, die werden alle korrekt ausgegeben. Wenn ich aber ["checked" => "checked"] mitgebe (also die setDefault-Methode umgehe) dann wird diese ebenfalls ignoriert... Echt merkwürdig... :(

[iceman-fx]

Klingt ganz danach, als ob man eher im Code von MForm nachschauen müsste. Vielleicht erwartet MForm irgendeinen speziellen Wrapper im HTML, welcher aufgrund des GB nicht da ist.

[dpf-dd]

Hallo Falko, ich habe heute das Problem nochmal inspiziert und bin fündig geworden.

MForm setzt den DefaultValue in einer Schleife:

        // set checked by value or default value
        if ($key == $item->getValue() || ('add' == $item->getMode() && $key == $item->getDefaultValue())) {
            $element->setAttributes(' checked="checked" ' . $this->parseAttributes($attributes));
        } else {
            $element->setAttributes($this->parseAttributes($attributes));
        }

Innerhalb von Gridblock wird diese Schleife nie durchlaufen, weil $item->getMode() IMMER edit ist und niemals add. Selbst wenn ich das Gridblock-Wrapper-Modul NEU erstelle und dann einen NEUEN Inhaltsblock hinzufüge, so ergibt $item->getMode() EDIT - weshalb mein Default-Wert ignoriert wird.

Die Frage ist jetzt: Wie löst man dieses Problem? Any idea? :)

EDIT: Korrektur. Das ist auch nur die halbe Wahrheit, da in der Schleife ja ein ODER abgefragt wird. Der erste Teil haut aber auch nicht hin. Außerhalb von Gridblock ergibt $key == $item->getValue() 1 == "1" und innerhalb von Gridblock aber 1 == ""... Ich inspiziere mal weiter...

1. Bild Modul OHNE Gridblock
2. Bild Modul INNERHALB Gridblock

[dpf-dd]

Hallo Falko,

also ich habe eine Lösung für das Problem, bin mir aber nicht sicher ob ungewollte Nebenwirkungen auftreten können...

Das Hauptproblem ist folgendes: MForm unterscheidet grundsätzlich zwischen $function = add und edit. Wenn ich in Gridblock ein neues "Untermodul" hinzufügen möchte, dann befindet sich sich $func aber im Zustand edit, da ich ja zuvor beim Wrapper-Modul auf editieren geklickt habe. D.h. es ist de facto unmöglich innerhalb von Gridblock ein neues Modul als Inhaltsblock hinzuzufügen und gleichzeitig $func auf addstehen zu haben. Aus diesem Grund liest MForm auch nicht die Defaultwerte, sondern versucht existierende Values auszugeben, die ja aber noch gar nicht existieren können.

Da ich diesen logischen Umstand nicht ändern kann, muss ich es mit einem Workaround versuchen... Mir ist aufgefallen, dass beim Hinzufügen eines neues Inhaltsmoduls folgende JS-Funktion getriggert wird: gridblock_loadModule(...) (/gridbock/fragments/gridblock/module_input.php, Zeile 402) In Zeile 410 ändere ich nun &function=edit in &function=add - damit schicke ich MForm die korrekte Flag (add statt edit) und schon funktioniert alles wie es soll.

Füge ich einen neuen Inhaltsblock hinzu, so werden meine Default-Values berücksichtigt und die Felder entsprechend belegt. Bereits existierende Inhaltsblöcke werden weiterhin geladen und mit den hinterlegten Values ausgestattet. Speichern und Editieren klappt alles perfekt.

Die Frage ist jetzt trotzdem: Könnte diese Änderung an anderer Stelle ins Verderben führen? Kannst du da mal kurz drüber nachdenken? Ich würde hier auch nen PR dazu zur Verfügung stellen...

[iceman-fx]

Hi Stefan, erst einmal vielen Dank für das Untersuchen des Problems.

Der Workaround kann in der Tat in anderen Modulen ein Problem werden, welche auch auf diese Variable zugreifen und "edit" verlangen. Es muss daher etwas weitgreifender umgesetzt werden, so dass sowohl "add" als auch "edit" korrekt gesetzt wird, je nach Art der Moduleinbindung.

[iceman-fx]

Ich habe noch einmal alles durchgeschaut. Es klappt doch mit Deiner Anpassung ohne dass Probleme mit anderen Modulen entstehen sollten.