feat: qcu options based on loop response#322
Conversation
nsenave
left a comment
nsenave
left a comment
There was a problem hiding this comment.
Le type pour les optionFilter correspond vraiment à un LabelType, d'ailleurs à vérifier avec @laurentC35 ou quelqu'un qui connaît bien Lunatic si on a pas besoin des maudits bindingDependencies dans le option filter, dans ce cas là utiliser le type ConditionFilterType
NB : si par défaut je préfère LabelType c'est qu'à terme j'aimerais virer l'objet ConditionFilterType et le remplacer par LabelType.
Cet objet "label" c'est celui qu'on utilise pour les expression VTL dans le modèle Lunatic
There was a problem hiding this comment.
Cette classe est quasi-identique à LabelType, ça me paraîtrait pertinent de la réutiliser
| protected String optionSource; | ||
|
|
||
| /** Optional filter for dynamic options. */ | ||
| protected OptionFilter optionFilter; |
There was a problem hiding this comment.
on peut refacto en protected LabelType optionFilter
| protected String optionSource; | ||
|
|
||
| /** Optional filter for dynamic options. */ | ||
| protected OptionFilter optionFilter; |
| Dropdown dropdown = new Dropdown(); | ||
| dropdown.setId("dropdown-dyn-id"); | ||
| dropdown.setOptionSource("FIRST_NAME"); | ||
| dropdown.setOptionFilter(new OptionFilter("VTL", "AGE >= 18", "FIRST_NAME")); |
There was a problem hiding this comment.
cf. refacto avec LabelType
dropdown.setOptionFilter(new LabelType());
dropdown.getOptionFilter().setType(LabelTypeEnum.VTL);
dropdown.getOptionFilter().setValue("AGE >= 18");
dropdown.getOptionFilter().setShapeFrom("FIRST_NAME");(ou pourquoi pas ajouter un all args constructor à LabelType)
|
There was a problem hiding this comment.
C'est bon par rapport à la PR Lunatic (JS): InseeFr/Lunatic#1296
Pas besoin des bindingDependencies ici
3 participants
This PR extends the Lunatic flat model to support dynamic response options
for QCU components (Radio, Dropdown, CheckboxOne).
Two mutually exclusive modes are now supported at the model level:
optionspropertyoptionSourceand an optionaloptionFilterThe Lunatic model remains flat and does not embed business logic.
As a consequence, the
optionsproperty is always serialized(even as an empty array) to preserve a stable and consistent JSON contract.
The responsibility for choosing between static and dynamic modes
remains in upstream business logic (e.g. mapping layer),
not in the Lunatic model itself.
Serialization and deserialization tests have been added to document
and secure this behavior.