En essayant de calculer des champs en y affichant des valeurs cochés sur une liste de valeurs, on s’est rendu compte que seule la valeur dans la langue de l’utilisateur courant peut être récupéré “facilement” avec un getDisplayValue, ce qui peut poser problème quand celui qui fait le calcul et celui à qui est destiné l’information ont deux langues différentes. Je pense que ça serait bien d’avoir un getDisplayValue mais avec un choix de la langue de la valeur à afficher.
Ce besoin est plus général que le cas particulier des valeurs d’une liste de valeur, il faudrait idéalement pouvoir accéder à toutes les traductions (libellés des items de paramétrage, valeurs des listes de valeurs & texte statiques, templates de publication, etc.) dans toutes les langues.
Les verbes au niveau de l’objet travaillent dans la session de l’utilisateur. La session est montée avec la langue de l’utilisateur, on ne peut pas charger toutes les langues dans toutes les sessions…
donc ce n’est pas dans cette mémoire qu’il faut chercher, il faut utiliser une autre session qui est dans la langue souhaitée ou alors chercher dans les couches plus basses.
Quand on parle de définition, il faut aller chercher dans le core cache qui factorise les définitions (field, list, object…) indépendamment le l’usage, droits, langues… cela optimise les clonages ultérieurs par session
Pour les valeurs de liste dans une langue donnée :
importPackage(com.simplicite.util.engine);
var cc = CoreCache.getInstance();
console.log("test API = "+cc.getListValue("ENU", "ACT_TYPE", "F"));
NB: attention quand même, ces APIs “bas niveau” ne sont pas des APIs publiques (d’où le besoin d’un import explicite), elles ne sont donc pas sensée être utilisées dans du code applicatif, en particulier cela veut dire que leur compatibilité ascendante/descendante n’est pas garantie (elles peuvent évoluer ou disparaître sans passer par la période avec un warning “deprecated” comme c’est le cas pour les APIs publiques)