Developpement de module : Etape 5

Retour à l'index

Structure interne, structures de navigation

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 ?)
• Quel est mon contexte de gestion ?
• Dans quelle phase je suis ?
• Quel role j'ai (à travers un test des capacités)

Les premier, deuxième troisième et dernier points font appel à des constructions standard de Moodle. Le quatriè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.

Certains modules proposent une variante qui consiste à définir le context module par l'identifiant de l'instance :

   $a = optional_param('a', , PARAM_INT);     // scheduler ID
   
   if (! $scheduler = get_record('scheduler', 'id', $a)) {
           error('Course module is incorrect');
   }
   if (! $course = get_record('course', 'id', $scheduler->course)) {
           error('Course is misconfigured');
   }
   if (! $cm = get_coursemodule_from_instance('scheduler', $scheduler->id, $course->id)) {
           error('Course Module ID was incorrect');
   }

Les deux stratégies sont comparables, elles conduisent toutes à obtenir une référence sur le "module dans le cours", sur "l'instance réelle" et sur le "cours" qui constitue le contexte d'action principal. Elles peuvent être utilisées conjointement, auquel cas les deux appels de paramètres sont optionnels (Cf. scheduler/view.php).

L'utilisateur est-il bien identifié ?

Ce point est réglé très rapidement par un appel standard :

      require_login($course->id);

L'echec de cette fonction fonctionne comme un piège et rammène l'utilisateur non connecté à la page de connexion.

Dans quel contexte de gestion je suis ?

L'obtention du contexte de gestion permettra par la suite d'interroger le système de droits pour obtenir toutes les prérogatives de l'utilisateur courant. Dans notre cas, il s'agit d'un contexte de "module" (le plus utile dans un module !), mais certains capacités pourraient être interrogées dans un contexte supérieur (CONTEXT_COURSE jusqu'à CONTEXT_SYSTEM). Il faudrait créer d'autres références sur des contextes.

   $context = get_context_instance(CONTEXT_MODULE, $cm->id);