« Developpement de module : Etape 5 » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
Ligne 1 : | Ligne 1 : | ||
[[Developpement:Modules d'activité | [[Developpement:Modules|Retour à l'index]] | ||
L'étape 5 consiste à définir précisément la structure interne du module, à partir du point d'entrée view.php. | |||
===Modules séquentiels=== | |||
Un module séquentiel est un module dont l'activité évolue selon un certain nombre de phases. Chacune de ces phases pouvant être exécutées par un certain nombre de rôles, voire tous les rôles. En général, les étapes se répartissent souvent entre les actions des étudiants et les actions des enseignants. | |||
La construction d'un module séquentiel suppose, pour pouvoir afficher la vue correcte, d'avoir répondu à quatre questions : | |||
*Dans quelle instance je suis ? | |||
*L'utilisateur est il bien identifié (et comme corollaire, qui est-il ?) | |||
*Dans quelle phase je suis ? | |||
*Quel role j'ai (à travers un test des capacités) | |||
Les premier, deuxième et dernier points font appel à des constructions standard de Moodle. Le troisième demande une intervention du concepteur, qui doit définir et apporter une variable "d'état" au module. Si cette variable est unique pour le module (tous les utilisateurs contribuent collectivement à la progression de l'état), cette variable est un des paramètres non-éditable de la table principale du module. | |||
Si les relations entre les différents acteurs doivent être dissociées par utilisateur (progression individuelle) ou en semi-collectivité (progression par groupe) alors une deuxième table indexées sur l'identité du porteur de contexte (l'individu ou le groupe) est indispensable. | |||
===Dans quelle instance je suis?=== | |||
Ce point est réglé par un premier segment de code standard (nous prendrons le module Brainstorm, qui présente l'ensemble des stratégies comme exemple): | |||
$id = required_param('id', PARAM_INT); // Course Module ID | |||
if (! $cm = get_record('course_modules', 'id', $id)) { | |||
error("Course Module ID was incorrect"); | |||
} | |||
if (! $course = get_record('course', 'id', $cm->course)) { | |||
error("Course is misconfigured"); | |||
} | |||
if (!$brainstorm = get_record('brainstorm', 'id', $cm->instance)) { | |||
error("Course module is incorrect"); | |||
} | |||
On remarque que le paramètre "id" désigne (presque) toujours le "module de cours" c'est à dire la représentation de l'instance de l'activité dans son contexte de cours. |
Version du 3 mai 2008 à 09:43
L'étape 5 consiste à définir précisément la structure interne du module, à partir du point d'entrée view.php.
Modules séquentiels
Un module séquentiel est un module dont l'activité évolue selon un certain nombre de phases. Chacune de ces phases pouvant être exécutées par un certain nombre de rôles, voire tous les rôles. En général, les étapes se répartissent souvent entre les actions des étudiants et les actions des enseignants.
La construction d'un module séquentiel suppose, pour pouvoir afficher la vue correcte, d'avoir répondu à quatre questions :
- Dans quelle instance je suis ?
- L'utilisateur est il bien identifié (et comme corollaire, qui est-il ?)
- Dans quelle phase je suis ?
- Quel role j'ai (à travers un test des capacités)
Les premier, deuxième et dernier points font appel à des constructions standard de Moodle. Le troisième demande une intervention du concepteur, qui doit définir et apporter une variable "d'état" au module. Si cette variable est unique pour le module (tous les utilisateurs contribuent collectivement à la progression de l'état), cette variable est un des paramètres non-éditable de la table principale du module.
Si les relations entre les différents acteurs doivent être dissociées par utilisateur (progression individuelle) ou en semi-collectivité (progression par groupe) alors une deuxième table indexées sur l'identité du porteur de contexte (l'individu ou le groupe) est indispensable.
Dans quelle instance je suis?
Ce point est réglé par un premier segment de code standard (nous prendrons le module Brainstorm, qui présente l'ensemble des stratégies comme exemple):
$id = required_param('id', PARAM_INT); // Course Module ID if (! $cm = get_record('course_modules', 'id', $id)) { error("Course Module ID was incorrect"); } if (! $course = get_record('course', 'id', $cm->course)) { error("Course is misconfigured"); } if (!$brainstorm = get_record('brainstorm', 'id', $cm->instance)) { error("Course module is incorrect"); }
On remarque que le paramètre "id" désigne (presque) toujours le "module de cours" c'est à dire la représentation de l'instance de l'activité dans son contexte de cours.