Filtre sur une relation d'objet

Bonjour,

Dans un formulaire de création, je souhaite sélectionner un objet associé via une relation 1-n.
Cependant, je souhaite appliquer un filtre sur la liste des objets proposés dans la pop-up avant que celle-ci s’affiche.
Pour que le filtre s’applique, dois-je passer par un initSearch ? Doit-il être placé dans mon instance en cours de création ou au niveau dans le code de l’objet lié ?

Cdt

Il y a plusieurs approches possibles pour filter une sélection de référence en fonction du besoin:

  • Mettre en place un link mapping, dans la plupart des cas c’est cette approche qui est la meilleure quand le filtrage est dynamique (ex: liée à la valeur d’un autre attribut de l’objet)
  • Coder la logique dans le hook initRefSelect si l’approche ci-dessus est trop limitée vs le besoin
  • Mettre en place un filtrage statique (dans le postLoad) en testant l’instance (via isRefInstance) si le filtrage est statique
    etc.

Bref, merci de préciser la nature de filtrage requis histoire qu’on puisse déterminer quelle est l’approche appropriée dans ce cas

Bonjour,

Dans notre cas, il s’agit d’une relation réflexive que l’on souhaite filtrer en appliquant plusieurs conditions de filtrages.

Dans notre formulaire de création, nous faisons référence plusieurs fois à cette réflexive, pour des besoins métiers différents. Cela implique des conditions de filtrages à appliquer différentes pour chaque lien.

2 questions pour l’implémentation de la méthode initRefSelect en java :

  • Peut-on identifier dans le code, le champs (le lien) sélectionné pour conditionner les règles de gestion ?
  • Peut-on utiliser un champ d’un objet hérité comme filtre ?

Merci d’avance pour votre retour.

Jean-Baptiste

  • Peut-on identifier dans le code, le champs (le lien) sélectionné pour conditionner les règles de gestion ?

On peut savoir depuis quel objet on selectionne la référence via getParentObject()

  • Peut-on utiliser un champ d’un objet hérité comme filtre ?

Oui bien sûr, un attribut hérité est un attribut de l’objet comme un autre, donc filtrable

Pour getParentObject(), dans notre cas nous avons deux (ou plus) recherches sur le même type d’objet lié dans le même formulaire, ce qui implique que getParentObject() renvoie la même valeur. C’est pour cela que je souhaiterai identifier le champ sélectionné par l’utilisateur.

Concernant l’héritage, mon filtre est actuellement positionné dans l’objet parent et je veux accéder à un attribut de l’objet fils. L’objet parent ne connaissant pas les attributs de ses fils, existe-t-il un moyen d’y accéder ?

Cordialement
Jean-Baptiste

getParentObject sera insuffisant pour filtrer en fonction du champ FK.

Il faut faire une petite évolution pour que l’instance “ref” accède au nom du champ FK du parent object.

getParentObjectRefField n’est pas valorisé dans le contexte de sélection de reference mais le peut facilement.

Oui effectivement.

Pour ce qui est de l’héritage je ne comprends pas vraiment le point, désolé. Un objet fils hérite des attributs du père en termes de definition uniquement. Pour Simplicité un objet père et un objet fils sont 2 objets distincts. Mais peut être ne parle-t-on pas d’héritage ici mais de relation…

J’ai fait la modif, à tester quand ce sera poussé sur vos instances.
Dans l’objet référencé, vous devriez normalement avoir accès dans votre initRefSelect au nom du champ via :

if ("myForeignKey".equals(getParentObjectRefField()) ...

Bonsoir,

j’essaye d’utiliser cette nouvelle possibilité sans succès…

Dans l’initRefSelect, this.getParentObjectRefField() ou parent.getParentObjectRefField() renvoient null…

NB: En cible, je souhaite pourvoir filtrer dans l’initRefSelect sur la FK d’une liste de relation n-n présentée en PillBox depuis le formulaire “grand-père”.

Je suis en Version=4.0.P23
BuiltOn=2019-05-22 18:34 (revision ece840f916282b8dcd268da53b9f2fa3dc832121)

Est-ce un problème de mise à jour de notre instance ?

Cette révision date du 22/05:

> git show ece840f916282b8dcd268da53b9f2fa3dc832121
commit ece840f916282b8dcd268da53b9f2fa3dc832121
Date:   Wed May 22 18:34:37 2019 +0200
(...)

NB: La révision à jour sur la branche release est:

> git log -n 1 release
commit b4dcc121cee1b86e41ba9d3091d49d85726fd4c3 (HEAD -> release, origin/release)
Date:   Tue May 28 11:12:59 2019 +0200
(...)

Bonsoir David,

merci beaucoup pour cette réponse très rapide.

De fait, nous ne sommes pas alignés sur la dernière release (pas d’auto-update). Je me demandais surtout si la release du 22/05 embarquait bien l’évolution du 10/05.

En fait, je pense avoir un peu mieux cerné le pb: si la table de relation est rendue en mode “liste fille”, j’ai bien l’info concernant le champ FK (comme indiqué dans le post de François).

C’est dans le mode de rendu pillbox que l’info manque. Le mode “liste fille” répond à mon besoin mais une fois que l’on a goûté à l’économie de clics offerte par la pillbox, c’est dur d’envisager autre-chose. J’espère que sera possible de faire quelque-chose pour ce mode de rendu.

ps: je viens de déclencher un nouveau build de la dernière release (j’attendais que la situation soit stabilisée suite aux aléas du début de semaine dernière).

pps: [Platform]
Status=OK
Version=4.0.P23
BuiltOn=2019-05-28 20:50 (revision b4dcc121cee1b86e41ba9d3091d49d85726fd4c3)… La suite demain.

ppps: je me suis débrouillé temporairement en jouant avec les noms d’instance (ref_ajax… / the_ajax…)

Bonne soirée à toi.