Contrainte visiblité champs en liste

4.0
Tags: #<Tag:0x00007fc9f3ba0f80>
Contrainte visiblité champs en liste
0

#1

Hello,

je suis en 4.0 et j’ai mis une contrainte de visibilité d’un champs conditionné par la valeur d’un autre champs. Le champs est bien masqué sur le formulaire mais il est toujours masqué sur les listes. Est ce que c’est voulu? comment faire pour afficher le champs en liste de façon intelligente?

En vous remerciant pour votre support

Zouhair


(François Genestin) #2

Il faut utiliser les constantes de Simplicité (cf javadoc)

  • ObjectField.VIS_FORBIDDEN : absent de toute UI
  • ObjectField.VIS_HIDDEN : dans la page mais masqué
  • ObjectField.VIS_BOTH : liste + formulaire
  • ObjectField.VIS_LIST : liste uniquement
  • ObjectField.VIS_FORM : formulaire uniquement

sinon le boolean est global

  • true = ObjectField.VIS_BOTH
  • false = ObjectField.VIS_HIDDEN

Dans l’expression de l’impact, pour afficher un champ en liste mais pas en formulaire par exemple

[VALUE:field]=="bob" ? ObjectField.VIS_LIST : ObjectField.VIS_BOTH;


#3

Hello,

j’utilise le module démo de la formation (avec les pizza) et j’essaie d’appliquer ce que tu as évoqué précédemment.
le but est d’afficher le diamètre des pizza en liste mais pas en formulaire sauf si type de pizza = “THIN”

donc je crée ma contrainte

Après je crée l’impact comme expliqué

Je clear le cache et je teste. ça marche en back-end mais en front-end ça marche la première fois quand je passe d’une autre valeur à THIN mais pas les fois d’après

Merci d’avance pour vos réponses.
Zouhair


(François Genestin) #4

Pas de problème sur l’IHM responsive.
vidéo https://www.useloom.com/share/4f1995e6ce6f4b98974b46abd6a7446f

Par contre les contraintes front ne sont pas appliquées (ou partiellement) sur l’ancienne IHM.
Il doit y avoir un pb.


(David AZOULAY) #5

Jouer dynamiquement sur la visibilité d’un champ sur une liste n’a pas vraiment de sens, ex: si un record rend le champ visible et le suivant non, est-ce qu’on cache la colonne ou on la montre ?

Selon moi le bon pattern c’est de ne pas mettre sur une liste des champs pouvant dynamiquement être rendu visible/invisible (ou alors il faut faire des listes dédiées avec des filtres adhoc)


(François Genestin) #6

Ce n’est pas la question. La question est le show/hide en formulaire contraint, sans impacter la liste (donc ne pas mettre true/false sur la propriété mais utiliser les constantes VIS_BOTH/LIST).

Ce qui ne marche sur le legacy c’est show/hide sur le formulaire, je pensais que cela avait été fait sur le projet d’Arun.

ps: visible/invisible en liste c’est masquer le contenu du <td>, pas la colonne. ça fonctionne.


(David AZOULAY) #7

Si le show/hide sur la page formulaire legacy marche, en tout cas, avec des expressions simples (je viens de vérifier sur une instance à jour).

cf. https://www.useloom.com/share/88b42afdf18549c4b7ad9d26cb4dbc04

Sur les formulaires en liste je ne sais pas mais je continue à penser que cela n’a pas beaucoup de sens d’afficher des champs à visibilité dynamique sur une liste.


(François Genestin) #8

Le besoin en liste existe aussi, ex masquer un numéro de téléphone sur les lignes où le contact est en liste rouge uniquement (bannette centrale de PRDV SFR…).

J’ai paramétré la contrainte pizza sur dev40 et elle ne marche pas, l’expression doit être trop compliquée.


#9

Je confirme qu’en UI responsive la contrainte marche mais en UI legacy le fonctionnement front-end n’est pas satisfaisant.

Est ce que ça sera corrigé? sinon ou en attendant, est ce qu’il y a une parade? par exemple, une expression qui me dit est ce que je suis en formulaire ou pas pour n’appliquer la contrainte avec le boolean global que si je suis en formulaire.

Cordialement,
Zouhair


(François Genestin) #10

Dans l’exemple de David ça fonctionne, donc je lui laisse la main pour te guider pour reproduire son paramétrage.

Il faudra utiliser l’IHM responsive de toute façon à terme, donc merci de nous dire ce qu’il te manque pour y passer définitivement, car l’autre te posera tout autant de pb à mesure que la nouvelle IHM aura plus de fonctionnalités.


(David AZOULAY) #11

J’ai testé en legacy: si l’expression est au niveau contrainte (et juste true/false au niveau impact) ça marche mais pas si l’expression est au niveau impact.

Je vais regarder ce que ça implique comme évolution pour gérer ça mieux.


(David AZOULAY) #12

Bon en fait le pb n’est pas là. Je suis en train d’investiguer… A suivre


#13

Peux-tu stp, pendant tes investigations, tester le cas où la contrainte de visibilité est appliqué sur un attribut récupéré via une clé technique. Exemple : je cherche à afficher /masquer le supplier d’un produit si un champs supplier connu = Y/N

Je crois que la contrainte même en UI responsive ne marche pas.


#14

Pour répondre à ta question : il nous manque quoi pour passer en repsonsive?

La reponse est :

  • Associer
  • Fusionner
  • Créer sur l’écran select (c’est très utile dans le legacy de ne créer un record qu’après avoir vérifié qu’il n’existe pas déjà)
  • la même diversité de clear cache que le legacy notamment le clea cache server qui nous est très utile
  • un Créer en liste avec le même fonctionnement que le legacy; dans le responsive ça ne marche pas ou plus depuis sûrement quelques semaines.
  • Supprimer un écran intempestif qui n’arrête pas de me demander d’enregistrer avant de quitter alors que je n’ai pas modifier un seul champs du record
  • etc. (je rajouterais d’autres items au fur et à mesure de ma découverte du ui responsive)

#15

Bonjour David,

Est ce que tu as pu avancer dans tes investigations?

Cordialement,
Zouhair


(David AZOULAY) #16

A ce stade j’ai surtout corrigé ce qui ne marchait pas correctement. Je te laisse tester dans tes cas particuliers pour voir si ces corrections améliore les choses.

Attention, sur la UI legacy le scope de prise en charge des contraintes coté client est (et restera) structurellement limité à des cas simples. Nous ne pourrons sans doute pas la faire évoluer très au delà de ce qu’elle fait aujourd’hui.


(François Genestin) #17

Ok merci pour ton retour, tout est déjà au backlog


(David AZOULAY) #18

Après investigation on a corrigé un pb qui impactait les contraintes de visibilité en front sur la UI legacy quand celle-ci utilisait la constante ObjectField.VIS_LIST.

Après analyse, vu la manière dont est implémenté l’edition en liste sur la UI legacy, appliquer les contraintes front nécessiterait des changements impactants qui ne sont pas raisonnablement envisageables dans le contexte actuel de la 4.0 (car trop de risques d’effets de bord).

Ce module pour tester dans un cas simple: https://www.simplicite.io/resources/modules/pizzeria-app-4.0.xml (data: https://www.simplicite.io/resources/modules/pizzeria-data-4.0.xml)

NB: Sur la UI responsive les contraintes s’appliquent correctement sur le formulaire comme en édition en liste.


#19

Je confirme que mon pb de visibilité en liste a été résolu.