Umgang mit Aufgaben, die für mehrere Programmiersprachen freigeschaltet sind

Es ist möglich bei Templates mehrere Sprachen einzustellen, allerdings kann man bei Freigabecodes dann nur eine Programmiersprache auswählen. Bei der Beispielaufgabe "Vollkommene Zahl" habe ich einen Freigabecode für Java und für Python3 (für alle ohne Freigabecode sichtbar) erstellt. Unschönerweise erscheint diese somit zweimal bei "Open exercises via visibility" ohne die Möglichkeit auseinanderzuhalten, welche Freigabe sich auf welche Sprache bezieht.

Momentan ist es so angedacht, dass Aufgabentext sowie Testfälle für alle angegebenen Programmiersprachen gelten, was auch sinnvoll ist. Es wäre allerdings sehr nützlich, wenn programmiersprachbezogen weitere Hinweise oder Testfälle erstellt werden könnten.

Beispiele

Programmiersprachenbezogene Hinweise: Ich möchte z.B. auf mögliche einsetzbare Biblitheken hinweisen, die naturgemäß je nach Sprache verschieden sind. Eventuell könnte man die genutzte Markdown-Sprache entsprechend erweitern: Sie dürfen die <python3>auf Listen definierte sort-Methode</python3><java>sort-Methode der Klasse Array</java> verwenden.

Programikersprachbezogene Tests: Ich möchte z.B. verhindern, dass bestimmte Bibliotheken verwendet werden, indem ich den Quellcode mittels regex überprüfe. Diese dürften sich wiederum zwischen Java und Python3 unterscheiden.

• [ ] Freigabecodes sollten auch so einstellbar sein, dass man mehrere Sprachen auswählen kann und der Nutzer beim Programmieren dann sich für eine entscheidet, allerdings müsste dann der Editor auch angepasst werden (umständlich)
• Die Übersichten (vor allem, aber nicht nur bei "Open exercises via visibility") sollten angepasst werden, dass ersichtbar ist, welche Sprachen jeweils erlaubt sind zudem sollte eine Filterung nach erlaubten Sprachen möglich sein.
• Bei der Aufgabenerstellung sollte die Möglichkeit geben pro mögliche Programmiersprache zusätzliche Hinweise per Markdown sowie zusätzliche Tests zu geben. (Es soll weiterhin Hinweise und Tests unabhängig von den Programmiersprachen geben!)

@apram Was meinst du? Jetzt bräuchten wir nur noch jemand, der das umsetzt...

added in need of improvement nice to have labels

Ich denke programmiersprachbezogen Hinweise sollte relativ leicht gehen, da muss man nur im Markdown Paket eine Erweiterung machen.

Freigabecodes für mehrere Programmiersprachen ist nicht so leicht, da müsste man das Datenbankschema anpassen (und alle Daten ändern). Vielleicht ist es einfacher einfach Freigaben "Für alle Sprachen" zu machen, da müsste man nur in der Spalte null erlauben. "Für alle Sprachen" ist glaube auch für die Open exercises via visibility am besten, warum sollte man es verbieten. Es müsste aber natürlich auch das Frontend angepasst werden, damit man dann eine Sprache auswählen kann bzw. die Sprache wechseln kann (damit man die Aufgabe in allen Sprachen lösen darf). Wenn man doch nur ausgewählte Sprachen freigeben will (in einer Freigabe), dann muss man schon mehr ändern...

Test nur für bestimmte Sprachen sind möglich, da muss man an den Tests eigentlich nur die Sprache speichern und dann überall, wo die Tests benutzt werden, danach filtern. Auch hier muss das Frontend angepasst werden.

Die Sprache bei "Open exercises via visibility" anzuzeigen ist da am einfachsten ;)

Also sehe da keine großen Schwierigkeiten, man muss nur die Zeit finden.

Wir können ja als Zwischenziel die beiden folgenden Punkte festhalten:

• programmiersprachliche Hinweise in Markdown ermöglichen
• Sprache bei "Open exercises via visibility" anzeigen
• bei "Open exercises via visibility" nach Sprache filtern

Bezüglich den Freigabecodes für mehrere Programmiersprachen: die saubere Variante wäre das Datenbankschema anzupassen. Das mit Freigabecode "für alle Sprachen" halte ich für ungünstig, da du die Abfrage, welche Sprachen erlaubt sind, ja nur verschiebst, anstatt es gleich sauber in der Datenbank vorzuhalten. Genauso gut könnte man die erlaubten Programmiersprachen in einen Wert codieren. Fände ich ebenfalls ungünstig. Letztendlich hat es den geringsten Mehrwert und stellt den höchsten Aufwand dar. Den Punkt würde ich streichen.

Das mit Tests ist natürlich eine spannende Sache, aber auch hier müsste man das Datenbankschema anpassen und es wäre auch denkbar, dass z.B. Test A für Java und Python gilt, Test B für Haskell, Test C unabhängig von der Programmiersprache usw. Eine neue Testkategorie einzuführen würde das Migrieren von Daten vermeiden, allerdings das Frontend unübersichtlicher machen und unnötig aufblähen.

changed the description