Attention : vous consultez actuellement la documentation dédiée aux versions 1.x de Moodle. La documentation pour les versions 2.x de Moodle est consultable ici : Developpement de module : Etape 5, celle pour les versions 3.x de Moodle est consultable ici : Developpement de module : Etape 5 et celle pour Moodle 4.x est consultable là : Developpement de module : Etape 5.

« Developpement de module : Etape 5 » : différence entre les versions

De MoodleDocs
Aller à :navigation, rechercher
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

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.