tout est expliqué dans ce post, dans le forum de développement de Moodle.
Cheers !
Salut Valery,
Je prends les custom labels. Je t'en ai parlé quelques secondes au Moot, ce module m'intéresse fortement pour aider à la rédaction de contenus pédagogiques pour les enseignants.
Je viens de passer en 2.7. Je m'en charge dans les 2 semaines qui viennent.
Bien cordialement
PS : est-ce que ça http://docs.moodle.org/dev/Render_library_specification va t'obliger à tout réécrire?
Philippe
Super Philippe !
Il est certain que les discussions en cours autour des "Course Elements", que mon module a contribué à initier vont sérieusement perturber la donne...
PS : Probablement en partie : dans un esprit d'amélioration continue des architectures, cet article définit très bien l'état actuel du problème de la séparation entre la logique et le rendu visuel. La question est épineuse et a fait couler beaucoup d'encre et fait proposer beaucoup d'architectures depuis 15 ans.
Moodle est l'un des rares opensource à arriver à une telle maturité que la communauté développeuse parvient à se saisir du problème, là ou de nombreux open source en sont encore à une problèmatique de librairie et de scripts.
On se rend compte en effet que les renderers dans Moodle sont un principe architectural qui porte la potentialité d'un découplage assez correct entre le rendu pur et la logique fonctionnelle, sauf que les concepts ne sont pas toujours appliqués, y compris (c'est le constat qui est fait) par les développeurs du core.
S'astreindre à une discipline de fer en ce qui concerne ce qui doit être dans un renderer et ce qui ne do t pas y être est une évolution extrêmement difficile à créer dans une communauté technique qui travaille beaucoup sur le principe du "consensus". L'article essaie de pointer comment évoluer par rapport à la pratique constatée existante.
Il est fréquent (et je ne parle même pas du code contribué, dans lequel je m'englobe évidemment), de voir tous les contournements de pratiques qui sont faites par les développeurs, par manque de connaissance de l'infrastructure, manque de temps, pression des objectifs, manque de la fonctionnalité exacte désirée, parfois paresse aussi. De ce fait, les "composants standard d'interface" sont ou ne sont pas mobilisés dans une grande divergence de pratiques.
Pour ce qui est des customlabels (Elements de cours en france), l'idée de repenser le module sur la base de renderers doit être examinée, afin que les exploitants puissent plus facilement "tuner" ces éléments. Cela a été longtemps une de mes préoccupations majeure dans ce module, sans être arrivé à une solution élégante jusqu'à maintenant (il faut surcharger les feuilles de style les icones et les templates, exercice techniquement complexe, et qui pose des problèmes de transport de ces éléments entre deux plates-formes différentes.
Pour l'instant leur forme convient aux programmes d'exploitation que je gère. Je ne pense pas qu'il y ait beaucoup de consensus de financement, malheureusement sur de la recherche appliquée en France sur cette question, Laissons donc avancer les HQ sur leurs propositions,... et nous verrons bien.
Tchô !