Dans #719 nous changions la structure de données Yaml de premier niveau
d'une liste vers un objet (indexé sur le nom des règles) pour les
fichiers Publicode. Ce commit réplique ce changement pour les fichiers
de tests de mécanismes qui n'avaient pas encore été migré vers le
nouveau format.
L'attribut "test" qui servait à définir le nom du test est supprimé et
on utilise maintenant directement le nom de la règle (ou son titre s'il
est défini) comme nom du test.
Gros changements en perspective :
- Supprime la notion de période, au bénéfice de celle d'unité
(`période : mensuelle` devient `unité: €/mois`)
- Améliore les rapports d'erreur avec des messages plus clair
- Ajoute un avertissement lorsque des types ne sont pas compatible
- Ajoute la conversion automatique d'unité dans le moteur
- Ajoute une notion d'unité par défaut de la simulation,
c'est l'unité vers laquelle les règles qui ne spécifient pas
d'unité seront converties
- Ajoute une notion d'unité par défaut des règles, qui spécifie
l'unité de la règle qui prévaut lorsque qu'il n'y a pas
d'unité par défaut de la simulation (utile pour les question ou
pour s'assurer du bon type d'une règle)
* Définition à partir du nom complet en notation pointée (plutôt que
comme deux attributs indépendants "name" et "espace")
* Structure de données de premier niveau "dictionnaire" plutôt que liste,
s'aligne mieux avec notre contrainte d'unicité des noms
* Possibilité de définir les règles à partir d'une liste dans les tests,
dans ce cas il ne faut plus utiliser l'attribut "espace" mais renseigner
directement la notation pointée dans le "nom".
Quand une variable est destinée à être saisie par l'utilisateur, on veut
qu'il saisisse 50, pas 0.5 pour exprimer 50%.
On pourrait lui faire saisir 50 et convertir en direct vers la vraie
valeur de 0.5, mais c'est compliqué aujourd'hui dans reduxForm
(l'attribut "normalize" ne suffit pas, car la valeur 0.5 sera visible
après un bref instant de debounce).
Je pense qu'il serai quand même mieux que nous stockions les variables
qui sont des ratios comme 0.5 et que l'UI se charge d'afficher et de
faire saisir ces valeurs sous forme 50%.
Les variables qui n'ont pas de période définie ne subissent aucune
transformation.
Les variables flexibles ont la période courante de la simulation.
Est-ce nécessaire d'introduire ce 'période: flexible' ? C'est sûrement
possible de ne marquer flexibles que les variables d'entrée, et de le
déduire pour les variables de calcul, mais ça semble compliqué.
Ce n'est pas très propre, mais difficile de faire autrement sans revoir
l'architecture des filtres, du cache, des sélecteurs de la fiche de paie
et du l'explicaiton des cotisations...
