Config en 1.8

ce qui aura changé c'est l'emplacement des def et des conf.

les defs sont tant que possible déplacés vers leurs modules.

Imperfections

une horrible liste hardcodée est utilisée dans une fonction function claro_get_conf_def_file($configCode)

Les .conf ont été déplacés dans un sous-répertoire de la racine.

Le but à moyen terme est de ne plus avoir qu'un rep claroline que l'on peut proteger en ecriture mais lecture web et un autre qui à l'inverse est accessible en écriture pour la plateforme mais protégé en lecture web, et qui peut-être supprimé (pour refaire une install)

Imperfection

toutes les configs sont dans /platform/conf/ Ce qui leur donne une co-notation de config "partagée" le désir est émis de pouvoir sous-classer les config de module, par module. On y placerait les configs qui ne sont utilisée que par LE module. ce qui permet de facilement supprimer les conf inutile si ont supprime le module

Les configs sont encore dans des variables "globales"

 $mavaleurdeconfig

mais une nouvelle fonction : get_conf permet de les récuperer.

Il est primordial de convertir toutes les utilisation directe des valeurs de config dans les script par un get_conf. quitte à dans un premier temps (mais ca serait dommage) de faire des $foo=get_conf('foo');

get_conf() propose un 2eme paramètres, intéressant et utilisé.

Il pose juste un petit problème, c'est qu'on ne sait pas encore si c'est une roue de secours, où une pratique propre.

Ce que je veut dire c'est qu'on ne sais pas encore si on considère que y avoir recours est une "facilité de transition" ou un usage correct. En tout cas en mode développement, si la fonction doit l'utiliser, elle le signale.

A priori, elle sont surtout là comme roue de secours. le tout est de savoir si ce sont des roue de secours évitable où pas. Un problème affirmé de ce paramètre c'est que si on a 2 get_conf('foo',bar) dans un ensemble de script, pour un même "foo", on peut avoir des "bar" différents.

Le but de cette fonction est aussi de passer doucement des variables "globales" $mavaleurdeconfig à l'utilisation de $_conf'mavaleurdeconfig' Ce tableau ne sera en fait pas très connu des développeurs d'outils (si ce n'est qu'il le veront bien s'ils regardent les fichiers de config généré) parce qu'il n'utiliseront que des get_conf pour les lire et des $conf_def_property_list pour les définir dans le .def

Pour passer à ces $_conf, il faut encore prévoir le cas des constantes, et adapter le générateur de formulaire de config. Mais le plus gros, c'est qu'il faut surtout être sur que get_conf a bien remplacé tous les appels directs à des valeurs de config.

config d'outil et config claroline

les config de claroline sont des config qui seront placé et créé par claroline à partir d'un .def

Lors qu'on intègre un outil, il a probablement son propre fichier de config et son propre fonctionnement.

Lors des première tentative, le rève était de pourvoir générer directement ce fichier de config à partir d'un .def

Cela posant des problèmes avec le passage à $_conf, et utiliser ce tableau présentant des réels avantages, l'idé de génération directe à été abandonnée mais la contourner n'est pas spécialement ardue.

Il suffira en effet, d'inclure le fichier conf généré par claroline en début du fichier de config original de l'outil, et de remplacer les "valeurs" de config dans ce deuxième fichier par des get_conf();

get_conf ne permet pas

• de cascader des valeurs de config, c'est à votre code à le faire

exemple

    $nbItemPerPage = get_conf('nbUserPerPage',get_conf('nbLineInpaginedList',20));

Le cascading des fichiers de config est le même que en 1.7 même possibilités et mêmes limites.

Les fichiers de config dont le nom est le claro_label de l'outil, peuvent être surécrit par un cours

Il suffit de créer dans le répertoire du cour un repertoire conf et d'y placer une copie du fichier "plateforme" et d'y modifier les valeurs.

Il n'existe aucun moyen pour l'admin d'éditer ces fichiers en ligne ni même de les détecter.