L’onglet “Informations générales” devient actif, ce qui n’est pas le comportement attendu (seul l’onglet actif avant le rechargement devrait rester affiché).
L’onglet “Description du traitement” reste en surbrillance et est toujours actif.
Les contenus des deux onglets (“Informations générales” et “Description du traitement”) apparaissent l’un au-dessus de l’autre sur le même écran, créant une confusion visuelle.
Le problème survient également lorsque je change le niveau de zoom (CTRL + molette de souris ou CTRL + “+/-”).
Les deux onglets sont alors simultanément en surbrillance, et leurs contenus respectifs s’affichent à la suite.
Lorsque je retire les onglets contenant des sous-objets, le problème disparaît totalement, ce qui suggère probablement que le bug est lié à ces intégrations.
Voici les onglets contenant des sous-objets (Suivi de conformité et Notifications) :
Non nous n’avons pas trace de ce genre de comportement bootstrap où 2 onglets sont actifs en même temps. Par défaut au reload (ou save ou zoom responsive qui fait aussi un reload), Simplicité recharge le dernier onglet ouvert, donc ici, il affiche l’onglet 2.
Avez vous des contraintes ou du code en front sur l’objet en question ou ses sous-objets ?
Par exemple du code qui force l’ouverture/focus sur le premier onglet ?
Il y a peut être du code qui ajoute la classe “active” sur l’onglet et la div content = les 2 deviennent visibles
Pour faire un toggle correct, il faut passer par $tools.setTabActive(tab, index).
/**
* @param {jQuery} t Tabs
* @param {number|string} index Tab index or tab data-key
*/
$tools.setTabActive(t, index);
ou alors y mettre un point d’arrêt, pour voir si les sous-objets ont aussi des onglets et que la UI s’emmêle les pinceaux entre les différents tabs/selectors. Essayez d’insérer vos 2 objets sans sous-tabs (l’un en dessous de l’autre dans l’onglet suivi) pour voir si c’est lié.
Merci pour votre retour. Après investigation, j’ai identifié la cause du problème d’affichage des onglets.
Le bug se produit lorsque l’objet incorporé possède des relations visibles (au moins sous forme de panels par défaut). Dans ce cas, ces panels sont intégrés directement dans la zone d’attributs configurée dans l’objet parent.
C’est précisément ce rendu des panels “incorporés” qui provoque l’affichage simultané de plusieurs onglets dans l’objet parent lors d’un rechargement, d’un enregistrement ou d’un zoom/dézoom de l’écran.
Lorsque l’objet incorporé n’a pas de relations visibles (ou que celles-ci sont masquées), le problème ne se produit pas.
Pensez-vous qu’il s’agit d’un comportement attendu de Simplicité ou d’un bug ? Y aurait-il un moyen recommandé pour éviter ce souci tout en conservant les relations visibles dans l’objet incorporé ?
Merci pour votre analyse.
Ce n’est pas un comportement normal, on va essayer de le reproduire pour le corriger.
On a déjà rencontré des cas où bootstrap se mélange les pinceaux entre les tabs / sous-tabs lorsque l’affichage est asynchrone.
Dans l’onglet “Other” du client, il y a un sous-onglet qui liste les commandes et les contacts du client. Le zoom ou le save ne mélange pas les onglets ouverts.
Vous n’avez pas répondu à ces questions :
Vous devez avoir du code ou quelque chose de différent, en tout cas votre formulaire semble bien plus complexe.
Merci pour votre retour. Je précise que mon problème ne concerne pas des listes intégrées dans des sous-onglets d’un onglet parent, mais bien un objet parent qui incorpore un autre objet, lequel possède des onglets en panel et est lié au parent via une relation d’objet :
Dans ce cas spécifique, les panels de l’objet incorporé sont insérés directement dans la zone d’attributs de l’objet parent. Cela entraîne le bug d’affichage.
Concernant vos questions :
Contraintes ou code en front ? J’ai testé en désactivant tout le code front et le problème persiste, donc il n’y a pas d’impact d’un code front en particulier qui forcerait l’ouverture d’un onglet ou ajouterait la classe active.
A ma connaissance, ce cas n’est pas géré mais ça fonctionne peut-être (partiellement), en tout cas c’est paramétrable.
Un objet inliné (de cardinalité 0,1 ou 1,1) dans un objet parent n’est pas sensé ramener ses propres relations (0,n) en cascade, ou récursivement d’autres relations 0,1 inlinés.
On va faire des tests en ce sens mais on touche aux limites du runtime à interpréter le méta-modèle.
Merci pour ce retour. Pas de souci, nous avons trouvé un workaround en agissant sur les relations dans les postLoad. Nous avons modifié le comportement en ajustant la visibilité des relations de l’objet incorporé directement dans cette méthode.
Voici ce que nous avons mis en place :
@Override
public void postLoad() {
warn("postLoad", "getInstanceName=" + getInstanceName(), this, -1);
if (isPanelOf("legalDataprocessAsDC") || isPanelOf("legalDataprocessAsSC")) {
for (Link l : getLinks()) {
if (l.getName().equals("RedoLog;rlg_object")) {
l.setVisible(true);
}
}
} else {
for (Link l : getLinks()) {
if (l.getName().equals("RedoLog;rlg_object")) {
l.setVisible(false);
}
}
}
}
Cela semble bien résoudre notre problème d’affichage des onglets.
Est-ce la bonne approche ou y aurait-il une meilleure façon de gérer ce cas ?
Si vous n’avez pas besoin des listes filles, il faut effectivement les masquer.
On va surement devoir limiter le fonctionnement natif pour ne pas les afficher dans ce cas.
Attention toutefois, il est préférable de masquer la Vue/View qui contient le Link et non le Link lui-même. Car la vue sert à l’affichage uniquement et cela aura uniquement un impact sur la UI.
Masquer le Link revient potentiellement à ne plus voir du tout la relation en back, y compris par exemple dans un export, ou un delete cascade.
De plus il n’est pas nécessaire de rechercher le lien, il y a des accesseurs par nom. Par exemple :
Merci pour votre retour et la clarification sur la différence entre masquer la Vue et masquer le Link.
J’ai appliqué votre suggestion en agissant directement sur la Vue via getView().setVisible() au lieu de masquer le Link, et effectivement, cela résout aussi notre problème d’affichage.
C’est donc la solution que nous allons retenir. Merci encore pour votre aide !
On va devoir retirer en 6.2, l’affichage des liens enfants d’un lien 0,1 inliné/affiché en formulaire.
Ce n’est pas un cas prévu alors que c’est possible niveau paramétrage, et visiblement cela pose pas mal de soucis côté front.
A revoir si le besoin de ramener des listes de liste 0,1 se fait sentir un jour. Mais ce sera toujours possible via lien virtuel.
