Valery Fremaux

Salut Hubert,

peux tu me donner la fin de l'URL de la page sur laquelle tu obtiens ce message ? Je l'ai cherché dans le code par un outil de recherche et ne l'ai pas trouvé tel quel.

La documentation "dans le code du module" (Readme) devrait te donner le minimum d'informations nécessaires.

Bonne chance.

Je reçois tous les avis de défaut si vous en trouvez. Il y en a probablement car le moteur lui-même est assez usine à gaz. Difficile de prévoir toutes ses réactions. Nous travaillons en commun avec les H.Q. à Perth pour le stabiliser définitivement.  

Le bloc global_search est un composant du moteur de recherche "full text" de Moodle. La mise en place de ce moteur est documentée dans la documentation Moodle.

Ce bloc donne accès aux écrans du moteur de recherche capable d'indexer et de chercher dans le contenu de documents déposés sur la plate-forme tels que HTML, DOC (Word), PPT (Powertpoints), PDF etc, mais aussi dans les divers documents que constituent les "rédactionnels" entrés dans Moodle à divers titre (par les activités).

Certains formats demandent la mise en place d'applicatifs annexes (des convertisseurs vers du texte brut, fournis dans les librairies de Moodle ou dans les contributions --- je pense que la distribution fournit désormais ces paquetages par les librairies, mais je ne m'occupe pas de cette partie là).

VF
Mainteneur/Développeur du moteur de recerche Moodle.

Basically for your first question :

How do module communicate to each other ?

There is many way to think about communication.

• One is actually formally implemented : using events. This way is only an asynchronous communication through an internal messaging implementation. A module that needs another module to update something could post a message in an event queue for that module.
• Another is practically used, but unstructured and should be probably better organized in the future : Some module do directly use the data model of another module. This is a form of hard coupling that should never be promoted, but we can collectively not avoid on new devs.
• An extension of the former strategy would be to reuse part of the other module API, either in lib.php or locallib.php of that module. This is more acceptable, unless locallib.php usually implements "internal" functions of the module.
• We proposed a fourth strategy as implementing a dedicated xlib.php that could implement special cross-module function entries. A way of cleanly uncoupling modules through a suitable frontend API. I have not experimented really this strategy but it is planned on a set of modules such as Techproject, Task and TimeTracker, so they work together.

Both latter strategies implies including the relevant lib file, acceding to the module filespace, generally using full path construction from $CFG->dirroot configuration path prefix. 

Second question : no idea right now.

http://www.ethnoinformatique.fr/course/view.php?id=37&lang=en_utf8

FIxes all reported bugs > 6 Feb 2008

• multiple selection in category (Etienne Roze)
• adds item deletion for manager (Fred Quay contrib)
• fixes report addslashes bug (Fred Quay)
• completes grading form and controller
• fix bad indexes (Philippe Verdenal)
• fix other little bugs