Developpement de module : Etape 5

Remarque : cet article est en cours de rédaction. N'hésitez pas à le compléter. Veuillez utiliser la page de discussion pour vos recommandations et suggestions d'améliorations.

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ée par un certain nombre de rôles, voir 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 corolaire, qui est-il ?)
• Quel est mon contexte de gestion ?
• Dans quelle phase je suis ?
• Quel rôle 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ée 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 contexte 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'échec de cette fonction fonctionne comme un piège et ramè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 certaines 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);

Dans quelle phase je suis ?

Le phasage est issu de l'interrogation du modèle de données spécifique au module. Dans notre cas exemple (brainstorm), la phase est collective. Elle dépend de la valeur d'un paramètre local du module appelé... "phase", et donc accessible directement via la variable $brainstorm->phase.

Quel rôle j'ai ?

La notion de rôle NE DOIT PAS ETRE INTERROGEE DIRECTEMENT par un développeur de module. Le rôle est en effet à prendre au sens de "profil de droits".

Pour savoir si on a le droit ou non de faire une opération, (ce qui indirectement découle du rôle que j'ai), il faut interroger les capacités par un appel à :

has_capability(...);