J’ai besoin de votre aide pour un comportement que je n’arrive pas a corriger :
j’ai deux objet liés entre eux, dans le formulaire d’update de l’objet parent ( Demande de renouvellement de soutien) , le fils ( Observations ) apparait sous forme de liste et est configuré pour permettre la création depuis cette liste.
Et il n’y a pas de message d’erreur dans les log a part ceci :
ICORED0001|public|com.simplicite.util.Grant|init|Info: public connected, session ID: 8F80A77B0DE48FE201643CE2C20A6838, timeout: 5 min , user agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.66 Safari/537.36 ui-bundle.js:490:304
JSON parsing error for ui-bundle.js:62:67
Dans un premier temps, j’avais créer l’association dans le mauvais sens, je l’ai supprimé et recrée mais en BDD les colonnes était toujours là, je les aies supprimées mais le problème persiste.
Est-ce que vous auriez une idée de l’origine du problème que je rencontre ici ou alors des pistes pour me permettre d’avancer ?
Je en vois à priori rien d’ “exotique” dans le paramétrage de votre objet lié que vous avez mis en copie d’écran. Est ce le seul cas de relation 1-N sur laquelle vous constatez ce pb de création (on est bien d’accord que votre pb c’est quand vous cliquer sur le buton “creer” de votre liste liée) ?
Peut être un effet de bord lié au fait que ça soit une liste embedded dans le formulaire, je vais tester. @Francois une idée ?
J’ai déployé une instance la plus iso (version Docker de simplicité et de postgresql) avec ce que vous avez : https://name.sandbox.simplicite.io j’y ai chargé la démo et j’ai modifié les objets produit et fournisseur pour être au plus proche de ce que vous décrivez et je n’ai pas de pb
Regardez dans les logs coté serveur s’il n’y a pas quelquechose qui pourrait vous mettre sur la piste
Avez vous du code dans les hooks de l’objet fils qu ne fonctionne pas : isCreateEnable, initCreate … ?
Si le JSON est vide en front c’est qu’il y a eu une exception en back dans la génération des meta-data. Ca se voit généralement dans les logs serveur.
Simplicité a des “try/catch” sur tous les appels de hooks mais pas sur les “simples” comme isCreateEnable qui du coup peuvent bloquer le fonctionnement de la UI si pas de réponse.
Mettez en commentaire votre code Java, et voyez si ça vient de là dans un premier temps.
On va ajouter des try/catch sur ces petits “hooks” aussi dans le moteur, mais il faudra toujours regarder les logs car même si l’écran s’affichera, il ne fera pas ce qu’il faut si le hook ne fonctionne pas.
Merci pour vos réponses, elles m’ont permis de trouver mon problème.
Dans la classe fille, j’ai un hook canListAccessNewForm avec un appel a getParentObject.
Si je met le getParentObject dans une lambda d’un stream, le premier appel suite au clique sur le bouton de création depuis la liste me retourne null et les suivants me retournent le parent :
if (List.of("REFUSEE", "ACCEPTEE")
.stream()
.anyMatch(in -> {
ObjectDB parentObject = getParentObject();
AppLog.info("Parent " + parentObject, getGrant()); // retourne " Parent null" pour le premier appel
AppLog.info("pour " + in, getGrant());
return in.equalsIgnoreCase(parentObject.getFieldValue("namRnvlDemandeSoutienEtat"));
})) {
return false;
}
Pour ma part je je peux facilement éviter le problème, encore merci pour votre aide :)
Il faut toujours tester si le parent est null avant d’y accéder, car suivant les contextes d’usage celui ci n’est pas toujours renseigné (metadata simple, creation depuis l’objet principale. kanban…)
Dans votre cas le premier appel récupère les meta sans contexte de l’objet pour l’instancier en front. Le second est bien issu du getForCreate avec un objet parent.
Donc dans mon cas ou le hook utilise le parent pour gérer un affichage, si le parent n’existe pas car le hook est appelé sans contexte, il est conseillé de retourner true ?
Ce hook retire le bouton “Create” en haut de la liste mais pas le droit de création donc le bouton “Créer en liste” sera accessible (via menu “plus” par défaut et si l’objet a cette option). En général, on agit sur le hook isCreateEnable qui est global à l’objet (et s’applique à tous les boutons de création côté front).
Par ailleurs, je doute que les hooks canXXX soient dans des try/catch(Throwable), on va renforcer ça aussi dans la construction des méta-data.
En soit tous les verbes de ObjectDB sont surchargeables en Java, mais on ne peut pas mettre des try/catch dans tous les appels dans le moteur.
L’idéal est de ne pas retourner d’exception dans vos hooks car Simplicité ne sait pas toujours bien réagir, et retrouver la cause peut s’avérer complexe quand on ne voit que les symptômes en front (ex json vide).
D’expérience un “null-pointer” se voit toujours dans les logs qui doivent donc être soit remontées sur la console du navigateur via websocket (paramètre utilisateur USE_WEBSOCKET_LOGS=yes sur votre user) ou toujours à portée de main via la UI ou un ssh tail -f.
