Rendre un attribut obligatoire dynamiquement sur l'IHM

4.0
Tags: #<Tag:0x00007f36180ea3a8>
Rendre un attribut obligatoire dynamiquement sur l'IHM
0.0 0

#1

est-ce-que tu peux m’envoyer un exemple de code qui permet de rendre un attribut obligatoire en fonction du contenu d’un autre attribut ?


#2

Sur la nouvelle interface V4 responsive, il suffit de créer une contrainte qui peut s’appliquer sur l’IHM :

  • Type = Expression
  • Expression = true (pour l’appliquer tout le temps), ou [VALUE:champ]==“val” pour l’appliquer uniquement si le champ vaut val, ou toute autre expression boolean ex: obj.getFieldValue(“champ”).indexOf(“REQ”)>=0 && grant.hasResponsibility(“ADMIN”)
  • Effets = front-end (exécution sur le navigateur) et optionnellement back-end (si la règle doit aussi s’appliquer via du code ou lors d’un import de données par exemple)

Et un impact :

  • Choisir l’attribut d’objet à rendre obligatoire
  • Propriété d’attribut impactée = Obligatoire
  • Expression = true | false ou une expression booléenne ex [VALUE:autrechamp]==“val”

On peut ainsi créer plusieurs impacts sur les champs pour forcer une valeur, une liste, masquer…

Pour les autres interfaces V3, il faudra faire du javascript client (via getField + onchange) car les contraintes ne sont pas implémentées coté client.


#3

quand je mets comme expression :
[VALUE:crePrestaStatut]==“ATTENTEFACTURE”

le carré rouge d’erreur apparait à coté de la ligne d’expression et contient :
"Expected a JSON value
Expected ‘]’ and instead saw 'VALUE’
Unrecoverable syntax error. (100% scanned)


#4

j’ai mi comme impact que le numéro de facture est obligatoire si le statut est “ATTENTEFACTURE”.

il y a bien l’étoile sur le champs N° de facture. je n’en saisi pas et je peux enregistrer sans pb. je n’ai aucun message d’erreur.


#5
  1. La syntaxe entre crochet est un héritage de la V3 qui n’est pas du javascript, en V4 il faut préférer utiliser les API javascript pour éviter que ACE Editor ne comprenne pas la syntaxe utilisée :

obj.getFieldValue("crePrestaStatut") == "ATTENTEFACTURE"

Cette syntaxe fonctionnera en javascript front et en javascripté serveur sur la V4.
Toutes les API java n’ont pas été portée en javascript client, mais les principales y sont pour les contraintes (ex obj.getFieldValue, obj.isMainInstance, grant.hasResponsibility…).

  1. Il faut que votre contrainte s’applique en Front et en Back.
    quelle est son “effet” ? il faut surement cocher Front + Back

#6

j’ai fait les modifs, ça fonctionne


#7

les champs deviennent bien obligatoire mais l’action et le changement de statut ne sont pas bloqués.
si je veux empêcher l’action de se réaliser et du coup ne pas changer de statut si les données ne sont pas saisies.
est-ce-possible ?


#8

Je comprends que le besoin est d’activer le bouton de transition d’état que si certaines conditions sont remplies.
Ceci peut se faire via une contrainte Front avec un impact sur l’action :

  • Cible = l’action de la transition
  • Expression = exemple : obj.getFieldValue("champ") != "" && obj.getFieldValue("statut") == "VAL"

L’impact qui peut s’ajouter à la contrainte existante si la condition est la même.

Sinon il faut laisser le bouton accessible, et ajouter un contrôle lors de la transition d’état dans le postValidate en comparant l’ancienne valeur et la nouvelle du statut.


#9

est-ce qu tu as de la doc sur toutes les nouvelles options des contraintes ?


#10

La docs sur les contraintes n’est pas à jour, mais le fonctionnement est identique à un 3.0 avec en plus en V4 :

La notion d’effet multi-valués :

  • Static : appliqué lors du load de l’objet (pour une règle liée aux droits par exemple)
  • Front : appliqué sur l’IHM (ex : regle pour afficher des champs/actions/vues dynamiquement)
  • Back : appliqué côté serveur (ex: regle métier obligatoire)

Et le fait de devoir écrire ses expressions en syntaxe javascript (les crochets sont substitués pas du code JS par compatibilité ascendante)

Pour le reste c’est inchangé, on peut toujours impacter un attribut, une vue ou une action.

On va mettre à jour la doc car les contraintes étaient assez peu utilisées en V3, maintenant qu’elles sont applicables sur l’IHM elles seront plus utilisées.