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
Il faut utiliser les constantes de Simplicité (cf javadoc)
ObjectField.VIS_FORBIDDEN : absent de toute UIObjectField.VIS_HIDDEN : dans la page mais masquéObjectField.VIS_BOTH : liste + formulaireObjectField.VIS_LIST : liste uniquementObjectField.VIS_FORM : formulaire uniquementsinon 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;
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
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.
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)
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.
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.
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.
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
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.
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.
Bon en fait le pb n’est pas là. Je suis en train d’investiguer… A suivre
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.
Pour répondre à ta question : il nous manque quoi pour passer en repsonsive?
La reponse est :
Bonjour David,
Est ce que tu as pu avancer dans tes investigations?
Cordialement,
Zouhair
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.
Ok merci pour ton retour, tout est déjà au backlog
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.
Je confirme que mon pb de visibilité en liste a été résolu.
