Bonjour, c’est encore moi
J’ai un nouveau cas d’usage avec des objets inlinés : en cas d’erreur de validation sur l’objet père, j’ai l’impression qu’on essaie quand même de créer les fils (avec du coup une clé vers le père vide)
Mode opératoire :
avoir un objet principal avec par exemple un champ obligatoire
et un objet inliné en 1,1
créer une instance du père sans remplir le champ obligatoire
→ le fils remonte également avec une erreur “clé vers le père manquante”
Oui le front effectue un save du parent puis du fils inliné.
L’idée étant de ne pas bloquer la mise à jour du fils même si le père a des erreurs, et de concaténer les messages de retour, car pour l’utilisateur c’est le “même” objet.
C’est vrai que dans le cas d’une création, si le père n’a pas été créé autant ne pas tenter de créer le fils. On va améliorer ça.
Du coup puisque dans ce cas le fils n’est pas créé, si le fils avait aussi des erreurs de validation back, elles ne seront visibles que lorsque la parent aura été créé / création en 2 temps si l’utilisateur fait n’importe quoi.
Il n’est pas possible de distinguer des erreurs qui relèvent de la création ou juste des données sans ajouter de la complexité déjà bien garnie.
Les liens 0,1 inlinés gérés par le front viendront a être remplacés par des objets composites générés par la back pour décharger la UI d’une combinatoire de plus en plus complexe. L’idée étant de fournir au front 1 seul objet, le mapping avec les objets liés/physiques devra se faire en back.
