Object externe non affiché

Tags: #<Tag:0x00007fdd4e1bd720>

Bonjour,

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 ?

Cordialement
Jean-Baptiste

Regardez la console du navigateur, il y a peut être des conflits entre le HTML/JS/CSS de vos différents objets externes.

Perso j’utilise un pattern de nommage “systématique” :

  1. le HTML utilise des ID uniques préfixés par le nom de l’objet externe, à commencer par un <div> dont l’ID vaut le nom de l’objet externe:
<div id="MyExtObj">
    ...
</div>
  1. Le JS définit un objet avec le même nom que l’objet externes:
var MyExtObj = MyExtObj || (function() {
    ...
    return { render: function() { ... } };
})();
  1. Le CSS utilise la syntaxe LESS de manière hiérarchique en commençant par l’ID du <div> ci-dessus:
#MyExtObj {
   p {
      color: blue;
   }
   ... 
}

Comme ça je suis certain que chaque objet externe est bien isolé des autres et qu’il n’y aura pas de pb si je les affiche en même temps.

Appliquez vous ce genre de patterns ?

Le pattern est bien appliqué pour les scripts.

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 ?

Voici les infos :

[Platform]
Status=OK
Version=4.0.P24
BuiltOn=2020-08-21 14:18 (revision 04e9f93a252dda1763a85f8c9bd81522b7dea211)
Encoding=UTF-8
EndpointIP=10.24.218.148
EndpointURL=http://frparvm36114048:8080
TimeZone=Europe/Paris
SystemDate=2020-09-25 18:37:13

Par acquis de conscience pouvez vous commencer par vous mettre à jour car cette révision est en retard de 40 commits correctifs sur la branche release

Bonjour,

Je viens de faire une MAJ du template, le problème persiste.

[Platform]
Status=OK
Version=4.0.P24
BuiltOn=2020-09-24 17:54 (revision 15c2ad3ac2a6ccc48119d5620f806db14ba59f15)
Encoding=UTF-8
EndpointIP=10.24.217.169
EndpointURL=http://frparvm82450142:8080
TimeZone=Europe/Paris
SystemDate=2020-09-28 10:07:00

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 ?

Je vous envoie un mail avec une instance et les informations pour reproduire le pb.

  1. 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)

  2. 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

  3. 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.

  4. 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.

Merci pour la solution de contournement.
Pour info, j’ai testé de mettre 1 seul et même droits sur les vues et le problème semble ne plus se produire.

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.

Hello @david,
tiens nous au courant quand la branche sera dispo et son nom, pour rappel on utilise la branch “release-light” actuellement.
Merci.

De mémoire vous tapez sur le repo Git du template d’instance 4.0 “template-4.0.git”, dans ce cas rien ne change.

L’évolution dont parle François a bien été poussée sur ce repo

C’est bien ça, Ok merci David.