Dans le même ordre d'idées, voici également le pack pour une solution de menus déroulants YUI (Ajax) développée pour Bibo (Hubert Zerbib) et que j'utilise sur http://www.ethnoinformatique.fr (voir à l'intérieur d'un cours).
Mais cette solution réutilise l'organisation en catégories de Moodle, sans créer une alternative de rangement.
La duplication de cours est vraisemblablement lourde et dangereuse. La synchronisation risque de devenir un "pensum" pour l'enseignant.
Une solution peu "académique", mais probablement très pragmatique serait de créer une simple page supplémentaire, ou plusieurs selon les modes d'accès, et de se forger "à la main" des catalogues de liens organisés de façon adéquate. Il est évident qu'une telle pratique ne peut être qu'une solution très locale car elle n'est pas très dynamique. Si on ajoute un cours, il faudra probablement réviser cette page. Mais c'est un moyen de sortir du système de catégories de Moodle, qui, comme tout logiciel d'organisation de quelque chose, ne peut proposer qu'un seul arbre de rangement principal.
Pour une réalisation pratique de ces pages, il suffit que ce soit des pages PHP qui reprennent au minimum :
<?php
include "<path_to_config>/config.php";
require_login(); // si elles doivent être privées
print_header(...) // capté dans un des nombreux fichiers de module.
...
?>
Le reste peut être des pures organisations de liens (en HTML) récupérées des listes de cours. C'est statique mais permet de proposer plusieurs accès distincts aux mêmes entrées de cours, pourvu que les cours ne changent pas tout le temps. Ceci n'empêche évidemment pas de choisir une stratégie d'organisation principale des catégories Moodle qui ait un "sens".
I fear we have all a local and context dependent ethnomethod to get rid of the rigidity implied in old deprecated get_course_students(...). These methods still are very usefull user status queries that are involved in many module scenarii.
I suggest H.Q. and core designers rehabilitate such functions, letting have the restricted meaning they will have. My question about moodle/legacy:student role wasn't so ingenuous : could'nt we status that this capability could map any role with student-like responsibilities to any custom role ? So could get_course_student be implemented a very simple way : checking availability of moodle/legacy:student in this course context and retreiving all users will have such condition verified. We could ensure ascendent portability of major code sections without bothering with such upgrades to follow.
NB : such a solution for all legacy roles, indeed !
Je vous laisse en pâture la dernière mouture abondament testée de mon côté. (mais il ne faut jamais dire jamais...).
Base de données identique (donc version inchangée).
Ce qui change :
).