dans le formulaire suivant, je souhaite empêcher la sélection du tuteur si aucun partenaire n’a été sélectionné au préalable.
Je le fais en javascript via l’attribut updatable qui positionne l’attribut ou non readOnly sur le champs. Sauf que le comportement n’est pas celui que j’attendais dans la mesure ou il agit sur la saisie manuelle au lieu de la selection.
Dans l’exemple j’interragi sur le champs ramené sur lequel la loupe est affiché, mais j’ai essayé également sur le champs de l’Id de l’objet lié.
Est ce le bon item sur lequel il faut agir et est-ce la bonne methode ?
A priori pas besoin d’écrire du code JS pour cela => à faire en contrainte.
Au passage ça vous assurera le respect de cette règle de gestion coté serveur (donc y compris si vous ne passez pas par la UI => ex: appel API ou import en masse) car les contraintes peuvent être front (UI) et/ou back (serveur).
Je pense que faire du métier dans la UI n’est jamais une bonne approche => Tout ce qui se passe coté client dans un navigateur web peut être facilement contourné et, comme dit précédemment, si vous interagissez avec vos données autrement que via la UI une règle métier uniquement implémentée niveau UI ne sera pas appliquée.
Pour le reste je laisse @Francois répondre à votre question JS
J’entends bien votre argument et je suis bien d’accord avec; dans un autre contexte projet je les aurai utilisé pour sécuriser au maximum la saisie utilisateur et surtout contre les petits bidouilleurs.
Des features passé m’ont démontré que la profusions de contraintes devenait ingérable vu la lourdeur de notre métier et de mon point de vue, j’essaie de limiter leur utilisation.
Dans ce cas vous devez réécrire la règle coté serveur dans un pre/postValidate (pas seulement contre les “pirates” mais aussi pour assurer qu’elle sera aussi appliquée via API ou I/O). Cela revient donc à écrire 2 fois ce que la contrainte fait, c’est juste dommage.
Pour le reste je n’ai pas l’expertise UI pour vous aider, je laisse @Francois vous répondre.
Le verbe front ui.updatable affecte juste la classe updatable ou readonly sur le .form-group du champ, et est plus réservé à un champ seul de l’objet. La FK est modifiable mais le champ joint est bien readonly au sens UI : gris non saisissable, juste sélectionnable via completion ou popup. Ce n’est pas la même notion en back et front.
Le .form-group d’un champ ramené est déjà .reference.readonly. Lui enlever la classe readonly aura des effets non désirés = pouvoir saisir un champ d’un autre objet, va aussi mettre à jour l’autre objet lors du save.
Il faudrait faire une évolution pour que ce verbe appliqué à une FK ajoute une autre classe (fk-readonly) à tous les champs joints qu’un CSS pourra interpréter pour masquer les boutons d’action (display none ou opacity 0 sur la loupe, le remove). Ca ne devrait pas être trop complexe.
Dans cette attente vous pouvez afficher/masquer le bouton loupe par jQuery.
$('.btn.refsel_field_<foreign key name>__<referenced field>', ctn).show()
ou hide().
Merci François. Quelle horizon pour cette évolution ?
Pour info, le sélecteur exacte est .btn-refsel_field_namConvstgCnctId__namCnctNom, si ça peut en aider d’autres. Ça répond pas tout à fait au besoin dans la mesure ou le champ reste cliquable quand même. Je vais devoir passer par une contrainte en attendant.
Hélas, la contrainte front ne va pas résoudre le problème.
car elle fera la même chose = appel au verbe updatable(true|false) qui est non adapté à une FK.
Il faut qu’on fasse l’évolution quand on applique la méthode front sur une FK pour ajouter une autre classe spécifique, car la notion updatable est “double” pour un champ joint (un champ joint est modifiable s’il est modifiable et que la FK l’est également).
Ca devrait pas être complexe à faire rapidement. je vous tiens au courant.
Votre code front (ou la contrainte) devra alors s’appliquer sur le champ FK et non sur un champ ramené.
Suite à analyse, il n’est pas possible de gérer tous les cas avec une simple classe, car l’input qui porte les actions du lien contient trop d’événements et de rendering.
Du coup, le verbe ui.updatable appliqué à la FK redessinera intégralement le champ qui porte les actions (loupe, click…).
Mon champ cible est bien inerte, par contre il ne devient pas modifiable pas lorsque je sélectionne un partenaire (pourtant le JS détecte bien un changement sur le champ namConvstgPrtId.
Autant les contraintes peuvent se révéler utiles, cependant on est limités en terme de débuguage je trouve et c’est une des raisons pour lesquelles on cherche à les éviter .
Grace au débugueur j’en conclu que je positionne bien la clause sur le bon champ. Mais cela ne m’explique toujours pas pourquoi le champ cible ne s’active jamais…
.