WYSIWYG-Editoren in Fragen-UI

[MHajoha]

Für die Einfachheit verwende ich, wie Dienstag kurz erwähnt, MoodleQuickForm_editor. Ich habe darin bisher noch keinen Nachteil erkennen können.

Text und Format der Editoren wird in einer separaten QT-Var editors gespeichert. Das Format ist zwar nicht das, was wir am Ende an den Server senden, da wir beides in der QPPE trennen wollen, halte ich es aber für sinnvoll, beides getrennt zu speichern, und qpy_response unverändert zu lassen.

editors ist, ähnlich wie qpy_response, ein JSON-Objekt von Editor-Name auf { "text": "", "format": "1" }-Objekt.

Die in Editoren hochgeladenen Dateien legen quasi den gleichen Weg wie die qpy:file-upload-Dateien zurück, werden also in der selben File-Area gespeichert. Vorm Senden an den Server werden dann editors und response_files zu einem Array von wysiwyg_editor_data-Objekten kombiniert.

TODOs (kommt in anderen PRs)

• Neue Felder in der QPPE-OpenAPI-Spec hinzufügen
• Im Text die @@PLUGINFILE@@-Placeholder durch qpy://response/<file_ref> oder so ersetzen @@PLUGINFILE@@-Platzhalter in Editor-Text in Responses durch QPy-URLs ersetzen #237
• Editor-Daten in summarise_response einfließen lassen: WYSIWYG-Editor-Daten in summarise_response einfließen lassen #236
• Datei-Metadaten an Server/Paket senden (Datei-Metadaten und WYSIWYG-Daten beim Scoring senden #232, dieser PR bearbeitet davon allerdings schon den Editor-Teil)

Erstmal ganz Out-of-Scope

• Copy-paste aus anderen Editoren supporten. (Müsste hier z.T. im JS passieren, ist also nicht so geschenkt wie bei den options)

Closes: #218

[MartinGauk]

TODOs

Copy-paste aus anderen Editoren supporten. (Müsste hier z.T. im JS passieren, ist also nicht so geschenkt wie bei den options)

Dann lassen wir das lieber. Finde ich nicht so wichtig.