Je suis devant un cas de hiérarchie entre deux entrées dans un objet métier. Cette relation de hiérarchie est matérialisée par un objet métier qui possède deux liens vers le même objet.
Le premier lien représentant l’enfant, le second, le parent.
Cette objet hiérarchie possède son propre formulaire :
L’utilisation “simple” de cet objet fonctionne. J’arrive à créer des hiérarchies entre deux instances.
Les ennuis arrivent lorsque j’essaye de restreindre les deux liste.
J’ai plusieurs règles à implémenter sur les choix possibles dans les deux listes mais pour faire simple, disons que la seule règle est que je ne peux pas choisir la même instance à gauche et à droite.
Pour l’instant, je suis en mesure de récupérer via du JQuery et un paramètre user le row_id de l’objet choisi (que ce soit à gauche ou à droite).
Je suis donc prêt à appliquer la règle dans le initRefSelect de l’objet pour le choix du second.
En revanche dans ce même hook, je suis incapable de savoir lequel des champs (gauche ou droite) a été cliqué.
Sénario :
click à gauche avec choix d’une instance → récupération du row_id
Si click à droite → utilisation dans initRefSelect du row_id stocké pour appliquer le filtre
Si click à gauche → pas de filtre
Et là est le problème, comment savoir dans le initRefSearch quel est le champ (dans le formulaire) qui a déclenché l’appel.
Effectivement le initRefSelect n’a pas directement l’info de la FK par laquelle on passe.
Avez vous essayé de mettre en place des link mappings (= le mécanisme standard prévu pour le filtrage conditionnel des sélections de référence) avant de vous lancer dans du code custom Javascript ?
Je pose la question car je ne sais pas trop comment ce mécanisme de link mapping va se comprter dans un cas de conditions croisées.
Mais bon sinon plutôt qu’une logique d’aide à l’utilisateur via des filtrages qui l’empêcherait de sélectionner certaines choses pas voulues vous devriez surtout mettre une règle de validation dans le postValidate qui renvoie une erreur si une sélection incohérente a été faite.
Je recommande de toujours commencer par implémenter ce genre de règles métier en tant que règles de validation serveur car ce qui se passe dans le client n’a strictement aucune fiabilité:
il suffit à qqu’un de malin de faire F12 et de bricoler le code HTML/javascript pour contourner les règles implémentées à ce niveau
idem si qqu’un passe par un appel d’API ou un import batch I/O il ne se verra pas appliquer ces règles UI
etc.
En fait quand on commence à implémenter de la logique métier au niveau client on fait nécessairement une grave erreur de conception : Les règles métier sont à implémenter d’abord coté serveur (typiquement dans les pre/postValidate), ensuite si on arrive à “aider” les utilisateurs à les pré-respecter aussi coté client, tant mieux mais ce n’est qu’une assistance à la saisie optionnelle, en aucun cas quelque chose de fiable.
Je ne souhaite pas implémenter de logique métier côté front mais côté back.
Grâce au row_id de l’élément sélectionné en premier, je peux réduire la liste des possibles pour l’utilisateur lors du choix du deuxième élément (le filtrage de la liste est fait côté back avant d’être envoyée au front) de cette façon rien d’autre que les valeurs nécessaires ne transite entre le back et le front.
De plus, je vous ai parlé de la liste la plus simple à implémenter (un élément ne peut pas être hiérarchisé avec lui-même) mais j’ai en réalité une dizaine de règles métier à appliquer.
Dans le cas du PostValidate, comment spécifié la raison de l’échec de sa tentative. Dois-je créer un pop-up résumant toutes les règles? ça me semble un peu lourd pour l’utilisateur…
Non pas besoin de me détailler vos règles mais ce que j’ai dit reste vrai : vos règles doivent impérativement être implémentées d’abord comme règles de validation (par exemple dans le postValidate) qui renvoient des erreurs bloquantes qui elles ne sont pas respectées.
Ensuite vous pouvez essayer, pour le confort de vos utilisateurs, de les “pre-vérifier” au niveau client (même si celui appelle ensuite un initRefSelect ou autre coté serveur) mais ça n’aura au final strictement aucune fiabilité.
En effet, sans parler du cas du “pirate” qui sait jouer avec le F12, le simple appel de l’API de votre objet zappera ces règles (car les initRefSelect ne sont pas appelés dans le contexte d’un appel d’API de mise à jour).
Bref je le redis: les règles métier de validation des données avant enregistrement doivent toujours être exécutées au niveau d’un pre/postValidate ou pre/postSave/Create/Update, le reste, quand c’est lié à des hypothèses sur un parcours utilisateur dans une UI, n’a strictement aucune valeur métier.
Cela étant dit vous pouvez bien entendu réutiliser/mutualiser votre code appelé dans vos initRefSelect pour ne pas écrire 2 fois les mêmes règles.
La règle métier en tant que telle est bien implémentée dans le back, au niveau du preValidate.
Le problèmle ici est plutôt du côté de l’UX. Il s’agit de présenter à l’utilisateur une liste de choix possible déjà filtrée et donc, cohérente avec la règle métier en back pour éviter qu’il ne se trompe.
