Zone d'attributs incorporés - getParentObject().getFieldOldValue(...) renvoie la dernière valeur enregistrée dans le parent

Bonsoir,

Je cherche à appliquer dans un sous-objet fils (incorporé) une règle de gestion s’appuyant sur les old values de l’objet principal (référencé).

Hors, depuis le hook preValidate de l’incorporé, getParentObject().getFieldOldValue(…) renvoie la dernière valeur enregistrée dans le principal (par exemple, les transitions d’état ne sont pas identifiables).

J’ai dans l’immédiat contourné le problème en passant par un paramètre de session (défini dans le preValidate du principal et récupéré/supprimé dans le preValidate de l’incorporé).

Bonjour,

Effectivement, il y a 2 appels consécutifs par le front pour enregistrer les 2 objets assemblés dans un seul formulaire. Du coup le second voit le premier déjà enregistré, sans se rappeler de ses anciennes valeurs en back.

Dans ce cas, il convient bien de faire passer un contexte applicatif entre objets via un autre moyen comme on le fait entre panels ou écrans, via un set/getParameter sur l’instance d’ObjectDB ou le Grant.

Par exemple sur le père :
initUpdate : setParameter("MY_CONTEXT_X", "");
preSave : setParameter("MY_CONTEXT_X", getFieldOldValue("x"));

Et sur l’objet lié :
preValidate : String x = getParentObject().getParameter("MY_CONTEXT_X");
postSave : getParentObject().removeParameter("MY_CONTEXT_X");

Une évolution intéressante consisterait pour la UI à appeler tous les “validate” avant de faire tous les “save” si tous disent OK. En l’état, les “save” sont disjoints et les messages back sont fusionnés par le front. Et il faudrait aussi ajouter un service Ajax “validate” qui n’existe pas seul.

:smiling_face_with_tear:

Si en plus le getParentObject() appelé dans les preValidate incorporés pouvait renvoyer le contexte du parent incluant les OldValues, alors là :star_struck: :hugs:!

En fait, oui ça marcherait pour les old-values en mémoire (depuis les get/select du départ), mais il n’y aura pas forcement les nouvelles valeurs encore envoyée en back dans un cas général de N liens embarqués.

Dans l’idéal, il faudrait donc que le front soit moins malin et envoie toutes les données au back dans 1 gros “saveAll” multi-objets, et le back ferait le travail en séquence :

  • request>setValues des N objets
  • les validate des N objets / retour si erreur sur l’un d’entre eux
  • et enfin les save des N objets

Je comprends… En même temps, si le front faisait moins le malin, on l’aurait dans le back. :rofl:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.