Nous avons un problème sur l’affichage d’une vue mapper à un objet externe depuis un formulaire.
Initialement, nous avions une vue (Vue 1) qui s’affichait bien sur notre formulaire.
Par la suite, nous avons ajouter 2 autres vues liées à des objets externes.
Depuis ces ajouts, la Vue 1 ne s’affiche plus (aucun appel Ajax n’est effectué).
Si nous retirons les 2 dernières vues, la Vue 1 apparait à nouveau.
Auriez- vous des pistes pour nous aider sur ce problème ?
Il n’y a pas de balise d’id sur le HTML mais je suppose que cette précaution sert pour l’application de styles complémentaires.
Ce que je ne comprends pas c’est pourquoi il n’y a pas d’appel sur l’objet externe lors du chargement du formulaire.
Autre point que nous avons remarqué, si nous visitons le template de l’objet (via un profil designer) et que nous revenons sur un formulaire, alors toutes les vues sont présentes.
Pas forcément juste pour les styles, si votre code utilise des sélecteurs avoir un ID au niveau le plus haut (et/ou des préfixes) permet d’éviter les ambiguités.
Sinon j’ai effectivement un souvenir d’un comportement comme celui là (le passage sur l’éditeur de template qui “résout” un pb d’affichage d’un objet externe embarqué dans un formulaire d’objet métier) mais il me semble ne plus avoir vu ça depuis très longtemps, (mais j’utilise en général la version 5, donc peut être un fix pas backporté ?). @Francois ça te dit quelquechose ?
Sur quelle version/patchlevel/révision exacte êtes vous ?
L’éditeur de template utilise le même algo de remplissage du template, avec un traitement pour le rendre éditable par dessus.
En V4, il n’y a pas encore d’objet externe directement dans un template, il faut soit coder (mettre une div dans le template à charger dans le form.onload), soit passer par une vue avec un item URL externe. En V5, on peut intégrer facilement un objet externe sans passer par un container/vue.
Il doit y avoir un problème de chainage ou de concurrence d’accès du chargement des 3 vues en parallèle.
Bref seul un debugger peut permettre de savoir pourquoi la vue ne se charge pas.
Avez-vous 3 vues d’1 zone ou 1 seule vue avec 3 zones ?
Que font les objets externes, travaillent-ils sur les mêmes instances d’objets en back… ?
Peut on reproduire le pb qq part où nous avons accès ?
Au chargement du formulaire la vue n’est pas là dès le premier GET avec les métadata de l’instance principale (the_ajax_SIOFEMere)
J’ai désactivé les 2 autres vues, elle réapparait : il y donc des incompatibilité entre les droits quand les vues de l’objet se chargent en mémoire
J’ai changer les Ordres des vues pour éviter qu’elles soient toutes à “10” : dans un hash ça aurait pu expliquer l’écrasement de l’une par l’autre. Mais ça ne change rien.
Au final, si le préventif ne marche pas, on passe au curatif :
j’ai contourné en ajoutant la vue explicitement dans le postLoad de SIOFEMere
car je suis incapable de trouver la cause au niveau des droits (je ne comprends pas trop comment les profils s’additionnent ou se soustraient vue leur nombre sur le role RF).
import com.simplicite.util.View;
//... dans le postLoad :
// Ajoute la vue SIOHistoriqueOccurence si besoin
List<View> views = getViews(); // liste des vues de l'objet
if (views!=null) {
boolean found = false;
// on cherche SIOHistoriqueOccurence
for (View v : views)
if ("SIOHistoriqueOccurence".equals(v.getName()))
found = true;
// La vue est bien habilité globalement ?
View v = getGrant().getView("SIOHistoriqueOccurence");
if (!found && v!=null)
views.add(v); // Forcer la vue dans cet objet
}
Ca reste un contournement, je vais regarder comment les vues de l’objet sont chargées dans Simplicité… il y a peut être une subtilité dans les ordres des Vues vs. des Relations d’objet (0,n).
J’ai trouvé une cause probable, c’est bien au niveau de la remontée des droits dans Simplicité quand il fait l’union des Vues parmi toutes les vues de chaque groupe habilité pour un objet donné.
Pour le user RF qui a 40 groupes liés, je pense que l’union des droits se passait mal.
On va livrer dès que la branche 4.0 sera passée en maintenance avec la sortie de la V5.
Oui c’est un bon moyen de contourner aussi, de mettre les vues dans un seul groupe pour éviter le merge qui en perd au passage.
La correction a été comitée mais encore perdue dans les méandres du packaging actuel de la V5 / maintenance V4. Il faudra voir avec @david pour vous caller sur la branche V4 maintenance, quand se sera possible.