La méthode readValues a été factorisée pour servir le saveObject et aussi le selectReference et selectDatamap pour envoyer les valeurs saisies “vues du front” pour un éventuel usage dans le hook back initRefSelect (pour filtrer les références en fonction du contexte).
L’idée était d’avoir la même règle/code pour préparer/forcer par hook les valeurs front “before save”, mais ici sans faire de sauvegarde quand on sélectionne une référence.
Le hook front beforesave pouvant bloquer le save, cela n’a pas trop de sens dans le cas d’une recherche de référence.
On va devoir séparer les 2 notions :
beforeSave = à limiter à la méthode saveObject
before/afterReadValues = nouveaux hooks pour modifier les données lues (avant usage qq soit l’appelant save ou ref select…) ?
Le code beforeSave qui modifierait les données lues, ne seront plus visibles de la recherche de référence, ce qui n’est pas toujours souhaitable. Mais on n’aurait plus le popup si le beforeSave affiche un popup + annule le save.
D’accord je comprends, sinon, il y a peut-être moyen d’indiquer au moment du beforeSave dans quel cas on est ? Ca permettrait de conditionner le code sans avoir à tout changer ?
Il permettra de modifier/completer les valeurs lues avant tout usage front. Ce sera avec callback explicite une fois réalisé pour permettre de lire des choses de façon asynchrone (un appel d’API…) comme le fait beforSave.
le hook beforeSave sera utilisé par saveObject uniquement.
Il permettra de faire des vérifications (bloquantes) avant appel au back.
