feat(ddi to lunatic): dynamic units #1175
Conversation
nsenave
commented
Dec 11, 2024
nsenave
commented
- Dynamic Unit on InputNumber #715
And add unit tests
nsenave
added
the
deploy-snapshot
|
👋 Version 3.31.0-SNAPSHOT deployed on docker hub |
github-actions
bot
removed
the
deploy-snapshot
|
@QRuhier @laurentC35 J'ai passé les type des labels d'unité en |
nsenave
added
the
deploy-snapshot
|
👋 Version 3.31.0-SNAPSHOT.2 deployed on docker hub |
github-actions
bot
removed
the
deploy-snapshot
| return null; | ||
| DynamicLabel label = new DynamicLabel(); | ||
| label.setValue(value); | ||
| // (type is left at its default value) |
There was a problem hiding this comment.
Hmm j'aurais pu skip tout le code que j'ai ajouté dans LunaticEditLabelTypes en faisant simplement un set ici j'ai l'impression, à refacto
| } | ||
|
|
||
| public static DynamicLabel createUnit(String value) { | ||
| if (value == null) |
There was a problem hiding this comment.
if (value == null || value.trim().isEmpty()) { throw new InvalidValueException("The value for DynamicLabel cannot be null or empty."); }
Ne serait-ce pas mieux de lever une exception ?
There was a problem hiding this comment.
Oui je comprends ta remarque c'est le signe d'une faiblesse dans la modélisation de cet objet, mais il a le droit de façon légitime de ne pas avoir de unit, dans ces cas là la prop reste à null donc pas besoin de créer un objet "label" sur la cible.
Ceci dit, au départ la méthode était en privée ici donc c'était pas trop gênant, mais entre deux je l'ai passée en public pour m'en resservir ailleurs, et dans le "cas général" c'est piégeux que la méthode puisse renvoyer du null en effet
Je vais essayer de refacto pour faire plus propre
|
nsenave
added
the
deploy-snapshot
|
👋 Version 3.31.0-SNAPSHOT.3 deployed on docker hub |
github-actions
bot
removed
the
deploy-snapshot
