Closed BulotF closed 1 week ago
Fonctionne actuellement dans Lunatic (estanp l'utilise dans ces tests)
@laurentC35 : avec la "syntaxe" proposée par Francois ?
@BulotF Comment est-ce qu'on peut reconnaître les variables calculées qui correspondent à du suggester à réponses multiples des autres variables calculées en DDI ?
@BulotF @romaintailhurat @AnneHuSKa
Les variables calculées seraient créées automatiquement par Pogues à partir des colonnes de la nomenclature
Cela est-il systématiquement le cas avec toutes les colonnes de la nomenclature ? ou est-ce que le concepteur choisit les colonnes qu'il veut pour les options de réponse ?
A mon sens, on doit imposer (la nomenclature untel comprend telle et telle colonne, on les crée, que le concepteur s'en serve ou pas). @romaintailhurat qu'en dis-tu ? @nsenave : tu sauras déterminer combien tu as de colonnes dans chaque nomenclature ? Ou c'est un paramètre de plus à décrire ?
@BulotF Comment est-ce qu'on peut reconnaître les variables calculées qui correspondent à du suggester à réponses multiples des autres variables calculées en DDI ?
Désolé, mais pour le moment, on ne peut les reconnaître que par leur formule. "left_join", qui est le début de la formule, n'est, en effet, pas compris par Trevas-JS (mais l'est par Trevas-Java)
A mon sens, on doit imposer (la nomenclature untel comprend telle et telle colonne, on les crée, que le concepteur s'en serve ou pas). @romaintailhurat qu'en dis-tu ? @nsenave : tu sauras déterminer combien tu as de colonnes dans chaque nomenclature ? Ou c'est un paramètre de plus à décrire ?
Pour moi, l'API Pogues-back-office fournira la liste des colonnes de la table (ce que ne fait pas le mock actuellement dans Pogues-IHM) et peut-être aussi leur format ?
Je ne sais pas comment l'IHM proposera de spécifier le label.
Par contre, j'imagine que l'IHM proposera pour chaque colonne de la table une variable collectée avec :
@AnneHuSKa
@nsenave : tu sauras déterminer combien tu as de colonnes dans chaque nomenclature ? Ou c'est un paramètre de plus à décrire ?
Oui Eno connaît les colonnes de la nomenclature à travers les "fields"
qui sont décrits dans le questionnaire Pogues / DDI.
@BulotF
j'imagine que l'IHM proposera pour chaque colonne de la table une variable collectée
La variable collectée en question, c'est la variable calculée avec le left_join dans le DDI ?
- affichage du format de la colonne (qui mériterait de venir du back)
Je ne vois pas ce qu'est le "format" de la colonne (du typage ? il me semblait que l'output d'un suggester est toujours du string)
✔ en QF sur ce questionnaire : https://conception-questionnaires.recette.insee.fr/questionnaire/m1holrzl 2 suggester avec les variables collectées SUGG et SUGGAZ 3 variables calculés :
calc_var = left_join($SUGG$, NOMENCLATURE using id, label)
calc_var_gaz1 = left_join($SUGGAZ$, NOMENCLATURE using id, label)
calc_var_gaz2 = left_join($SUGGAZ$, NOMENCLATURE using id, qte_fact)
On obtient le résultat suivant :
Lorsqu'on utilise un Suggester, on peut avoir dans la nomenclature des colonnes autres que l'identifiant et le label. On souhaite pouvoir récupérer les valeurs en même temps la variable contenant l'identifiant et les valeurs incluses dans d'autres colonnes.
1) Au niveau du DDI, le principe est que ces variables peuvent se calculer. Il existe même une formule VTL pour cela : on va chercher dans la matrice nomenclature une valeur dont on connaît l'identifiant de ligne et la colonne :
avec :
L'idée serait de créer une variable calculée de nom CALCULATED_VARIABLE_NAME contenant cette formule. Cette variable calculée ne serait pas transformée en variable calculée Lunatic, mais en OptionResponses du Suggester.
2) Au niveau de Lunatic :
Les variables calculées seraient créées automatiquement par Pogues à partir des colonnes de la nomenclature avec "CALCULATED_VARIABLENAME" qui serait initialisé à : SUGGESTER${RESPONSENAME}${ATTRIBUTE_NAME_IN_NOMENCLATURE}