`Attempt.onLoad()`- und `Attempt.onSave()`-Callbacks

[janbritz]

Dynamisch erstellte Form-Elemente sollten kein name-Attribut haben, da Moodle sonst diese Formdaten abspeichert und bei einem erneuten Laden versucht, diese Felder zu befüllen. Das ist allerdings nicht möglich und führt auch zu einer Fehlermeldung (questionpy-org/moodle-qtype_questionpy#149).
Stattdessen sollten diese Formdaten in einem hidden-Inputfeld gespeichert werden und das Paket sollte dann selbst die Felder befüllen.

Dafür sollten es Attempt.onLoad()- und Attempt.onSave()-Callbacks geben.

[MartinGauk]

Ich überlege, ob wir diese Daten statt in hidden-Inputfeldern im Attempt speichern sollten. Das LMS muss dafür sorgen, dass beim Anzeigen der Frage die (vorher ggf. gespeicherten) Daten im Objekt liegen und von dort beim Speichern der Antworten wieder geholt werden.

Mein Gedanke wäre, dass wir das qpy_response JSON dafür ebenfalls nutzen könnten, z.B. wenn der key mit _ beginnt, wird der Fehler ignoriert, dass kein Feld mit dem Namen existiert.

Ich glaube, Callbacks reichen an der Stelle nicht unbedingt. Wenn die User auf der UI etwas ändern, müssten veränderte Werte festgestellt werden, z.B. durch einen expliziten Aufruf Attempt.set_data(key, value) (oder so), damit das LMS wiederum informiert werden kann, dass eine Veränderung stattfand und ein Autosave passieren sollte.

Hast du eine Meinung, @MHajoha ?

[janbritz]

Ich finde es auch schöner, wenn nicht zusätzliche Elemente in der <form> auftauchen (auch wenn sie hidden sind).

Meinst du das alle dynamisch erzeugten Felder(-Namen) mit einem _ geprefixt und so abgespeichert werden? Dann müsste man aber vorsichtig sein, dass es nicht zu Names-Kollisionen kommt. Eine Überlegung wäre es auch ein extra Feld im qpy_response, z.B. @data, was dann die Daten JSON-encoded enthält.

Das stimmt, an diesen Fall hatte ich gar nicht gedacht. Ich probiere gerade aus, ob man nicht einfach mit einer Map arbeiten kann, auf die dann per Attempt.data zugegriffen werden kann.

[MartinGauk]

Die Idee gefällt mir, dass wir alle dynamischen Daten in ein eigenes Feld packen. Das müsste nicht unbedingt ein richtiges (hidden) Feld sein, sondern kann auch im formdata Event dynamisch hinzugefügt werden und aus der Map in Attempt.data erzeugt werden.

@data hat mir vom Namen zunächst gerade sehr gut gefallen, weil die Wahrscheinlichkeit gering ist, dass jemand sein Feld auch so nennt, aber hat in Verbindung mit Pydantic Nachteile, weil man mit einem Alias arbeiten müsste. Wir können auch einfach festlegen, dass es kein echtes Feld namens data geben darf. Im SDK kann ja eine entsprechende Überprüfung mit Warnung eingebaut werden und das Moodle-Plugin ignoriert schlicht Felder mit diesem Namen.