Open esandier opened 3 years ago
Je trouve ça très bien !
Et ce modèle doit pouvoir se généraliser à une structure d'exercices en arbre.
J'aime beaucoup l'idée du pipeline pour passer des paramètres d'un exercice à l'autre. Mais, dans beaucoup d'actitvités, on aurait juste besoin de générer la liste des exercices avec des paramètres de surcharge au début de l'activité.
Voilà une proposition.
Il nous faudrait une classe Exo
pour représenter un exercice (un peu comme la classe Component
). On pourrait construire un exercice dans le before
de l'activité en utilisant cette classe. Les paramètres du constructeur Exo
seraient l'adresse du fichier source pl et (optionnel) un dictionnaire de surcharge.
A la fin du before
, il faudrait avoir construit une liste liste_exos
d'objets Exo
.
Cette approche est compatible avec le pipeline (on update l'objet Exo
avec le dictionnaire du pipeline en temps voulu).
@ exo1.pl
@ exo2.pl
@ exo3.pl
@ exo4.pl
@ exo5.pl
before ==
from random import sample
names = ['exo1.pl', 'exo2.pl', 'exo3.pl', 'exo4.pl', 'exo5.pl']
for name in rd.sample(names, k=3):
lst_exos.append(Exo(name))
==
@ step1.pl
@ step2.pl
@ step3.pl
before ==
from random import randint
value1 = randint(1, 10)
value2 = randint(1, 10)
dicparam = {'param1': value 1, 'param2': value2}
lst_exos = [Exo('step1.pl', dicparam),
Exo('step2.pl', dicparam),
Exo('step3.pl', dicparam)]
==
Ce serait utile pour les exercices de vocabulaire.
@ exomodel.pl
before ==
from random import sample
data = sample(range(1, 10), k=5)
for value in data:
lst_exos.append(Exo('exomodel.pl', {'param': value}))
==
Tout à fait d'accord avec l'idée de classe Exo
, qui serait bien utile dans le contexte d'une activité.
Les exemples ci-dessus sont tout à fait le genre de chose qui iraient dans le before
de l'activité.
Pour ce qui est du pipeline
, il me semble que c'est le play_activity
qui devrait se charger d'assurer la transmission éventuelle des données d'une étape à l'autre.
Balises
Paramètres
liste_exos = exo1, exo2, ...
coeffs = {c1, c2,...}
Le coefficient de chaque étape dans le score final.one_way = true/false
True
, l'utilisateur doit valider l'étape i pour accéder à l'étape i+1.False
, la validation se fait à la fin, pour toutes les étapes en même temps. Entre temps, l'utilisateur peut naviguer librement d'une étape à l'autre. Ceci implique que les étapes sont indépendantes.affichage_score_partiel = true/false
True
, à chaque validation d'étape, un score est calculé à chaque validation d'étape, et affiché.False
le score n'est calculé et affiché qu'après validation de toute les étapes.affichage_solution = true/false
True
, à chaque validation d'étape, la solution est affichée.affichage_correction = true/false
True
, à chaque validation d'étape, la correction de l'étape est affichée.autoriser_corriger = true/false
True
, après validation l'utilisateur a le droit de corriger sa réponse et revalider.Balise Before (optionnel)
Comme d'habitude, du code qui initialise des variables
Balise Pipeline (optionnel)
Décrit le passage d'informations de l'étape n à l'étape n+1. L'étape 0 est le before, l'étape N+1 est l'evaluator. Les exos sont numérotés de 1 à N.
Pour i = 0..N,
Pipeline[i]
est un dictionnaire, où les clés sont des noms de clés du dictionnaire généré par l'étape i, et les valeurs sont des noms de clés du dictionnaire fourni en entrée à l'étape i+1.Un couple
{a:b}
dansPipeline[i]
signifie que la variablea
générée par l'étape i est injectée dans la variableb
fournie à l'étape i+1.Note: Par défaut, chaque étape 1,..N fournit un score et un feedback qui sont accessibles à Evaluator.
Balise Text
Comme d'habitude, l'énoncé.
Balise Form
Une page Html, avec des conteneurs pour les exos 1, 2, .., N
Balise Evaluator
Calcule Le score final et le feedback à partir des données fournies par les étapes 1..N.