Valery Fremaux

Pour le passage de "Projet" en groupes la fonctionnalité est en effet intéressante. La plupart des projets se font en effet en binôme et en trinome, et c'est important que les documents de projets puissent être mutualisés sur l'ensemble du groupe (en mode séparé ou visible).

Pour les dates de soutenances, c'est moins intéressant : le module Scheduleur, entièrement rénové permet déjà de gérer ce problème, y compris à partir de créneaux de groupes (je suis en train de gérer 180 soutenances de bases de données 1ère année comme un charme avec ce module - 15 minutes de retard max et aucune annulation non prévue sur 110 rendez-vous).

Pour l'attribution des notes, le module Scheduler les prend en compte déjà, mais c'est une note de soutenance. Si tu veux un carnet d'évaluation plus détaillé, Techproject est un exemple de notations multicritère où l'enseignant construit le jeu de critères qu'il veut. Tu peux t'en inspirer. Tu pourras à ce moment donner une note de soutenance par le Scheduler, et donner une note "de projet" depuis Projet.

J'ai prévu d'ajouter à Scheduler la possibilité de booker un groupe Moodle présent dans le contexte directement sur un créneau. Voire si j'en ai le temps, de commuter l'ensemble du booking en mode groupes exclusifs, où seuls les groupes constitués seraient bookables. Si tu places un Projet dans le même environnement, on partage alors les définitions de groupes, cool, non ?  

Tout à fait d'accord, $data contient un tableau associatif des valeurs de paramètres de cofiguration du bloc récolté dans le formulaire, ainsi que quelques clefs supplémentaires pour identifier le contexte.

$data['text'] ne correspond donc à rien par rapport à l'exemple de formulaire fourni.

Cette fonction est un "hook" intervenant juste avant la phase de sauvegarde des paramètres. On peut y imposer une valeur par défaut d'un paramètre manquant, aussi bien que comme le propose Jean, dans le formulaire côté client.

Le doublement d'une clef primaire par un index n'a aucune incidence sur le fonctionnement de la base de données. On peut éventuellent supprimer les indexes surnuméraires dans les tables, mais comme dit Joseph, tant que ça marche...

Ces index sont générés abusivement par l'éditeur XMLDB de Moodle sous certaines conditions. Il s'agit donc plus d'un simple avertissement de quelque chose d'inutile.

Il faut surtout examiner block_base qui contient l'essentiel des fonctions d'API du bloc.

L'essentiel de la production du contenu d'un bloc se fait en remplissant la variable $this->content->text dans la fonction get_content() du bloc, et de faire retrouner cette variable par la fonction.

Etienne, pour info, je viens d'être TRES OFFICIELLEMENT chargé d'un gros projet d'intégration dans notre école qui va je pense dans ta direction. Nous avons six mois pour réaliser une connexion lourde entre Moodle et ce que l'on appelle un référentiel de document basé sur la norme JCR170 (en l'occurence, il s'agit d'une plateforme EXO, leader de l'implémention des JCR). Au passage, je serai amené à étudier les évolutions actuelles du portefolio et des API de référentiels, tel que décrit dans http://docs.moodle.org/en/Development:Repository_API .

Ce projet doit (en théorie) m'occuper 3 jours / 5 à partir de maintenant (ça c'est pour la théorie), rémunéré par mon école. C'est l'officialisation de l'entrée de Moodle chez nous, après 4 ans d'ignorance...