Skip to content

WYSIWYG-Editor und Upload-Feld in Options unterstützen #199

@MartinGauk

Description

@MartinGauk

Ich lege das Issue stellvertretend hier an. Es betrifft aber auch die anderen Repos.

Bitte ermögliche es, dass in den Options auch Felder für Texte mit Markup (ggf. WYSIWYG-Editor) und Upload-Felder hinzugefügt werden können. Ich packe beides in dieses Issue, weil bei Moodle Textfelder/WYSIWYG und Dateiuploads miteinander verknüpft sind (in fast allen Textfeldern in Moodle können auch Dateien hochgeladen werden).

Beide Themen sind nicht unkompliziert.

Textfelder mit Markup

Moodle unterstützt mehrere WYSIWYG-Editors (HTML) und man kann alternativ auch auf Plain-Text oder Markdown schalten. Daher speichert Moodle neben dem Text auch immer das Format ab. Dem Paket wird in den Formulardaten ein Objekt übermittelt, das text und files (nur Referenzen) enthält. Das LMS kann aber auch noch eigene weitere Felder hinzufügen, die mit Unterstrich beginnen. Die Pakete sollten zur Speicherung im question_state oder zur Einbettung im Fragentext text lieber unverändert lassen oder nur einfache Textoperationen durchführen (z.B. Textstellen / definierte Platzhalter ersetzen), aber nicht versuchen das Markup zu verändern. Das könnte notfalls per JS im Browser noch gemacht werden.

Für das Einfügen im Fragentext müssen wir noch die Processing Instruction erweitern. Das sollte aber besser in einem eigenen Issue erfolgen.

Upload-Felder

Es können mehrere Dateien hochgeladen und auch Ordner erstellt werden. Die Dateien in einem Upload-Feld werden später unter einem Tupel aus (component, filearea, contextid, itemid) gespeichert. Wenn das Formular wieder aufgerufen wird, werden die Dateien zum Bearbeiten in eine draft area kopiert mittels file_prepare_draft_area. Normalerweise wird jedes Upload-Feld genau einem dieser Tupel zugeordnet. Ich halte es in unserem Fall für nicht so gut, wenn wir mehrere fileareas kreieren und diese nach den Feldnamen bestimmt vom Paket benennen. Ich denke, wir sollten alle Upload-Felder, die in den Options definiert sind, in einer file area options abspeichern und darin Unterordner mit dem Feldnamen erstellen. Ist das praktikabel? Wir könnten eine eigene file_prepare_draft_area Funktion schreiben, die die Unterordner berücksichtigt und in jeweils eigene draft areas kopiert. Die Original-Funktion ist nicht so umfangreich.
Zum Speichern wird normalerweise file_save_draft_area_files verwendet. Die Funktion ist schon umfangreicher. Eventuell wäre es sinnvoll, vor dem Aufruf dieser Funktion alle Upload-Felder in Unterordner einer neuen draft area zu speichern!?

Mir fällt gerade auf, dass wir in der QPPE die Namen von Formularelement beschränken auf ^[a-zA-Z_][a-zA-Z0-9_]*$, was ich sehr gut halte. In _BaseElement.name wird diese Beschränkung aber nicht validiert. Das sollte noch nachgeholt werden. Wenn wir diesen Unterordner-Weg gehen, ist es eventuell besser, wenn die erlaubten Zeichen beschränkt sind.

Dem Paket werden nur Referenzen übermittelt, mit denen es später per LMS Callback API die Dateien abrufen kann, wenn es das will. Anders als bei den anderen Feldern würden wir dem Paket damit keine Möglichkeit geben, die Dateien oder die Dateiliste abzuändern, was in Ordnung sein dürfte. Wenn eine Datei verändert im Fragentext verwendet werden soll, könnte das Paket die veränderte Datei perspektivisch in den question_state_files abspeichern. An konkreten Informationen könnte das Paket erhalten: Dateiname/Pfad, Dateigröße, Referenz.

Sub-issues

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions