Bonsoir, je ne sais pas s’il s’agit d’un bug ou d’une feature request mais je pense rencontrer un problème similaire à celui traité dans le post cité plus haut. Je classe le post en support dans le doute…
Dans le cas présent, je dois pouvoir filtrer les éléments dans la pillbox en fonction du rowId de l’objet courant qui présente la pillbox. Hors je n’arrive pas à remonter à ce contexte depuis le hook preSearch de l’objet présenté dans la pillbox:
getParentObject(), getParentRefField(), etc. renvoient tous null
getInstanceName() renvoie un nom d’instance tmp_xxx mais pas panel_xxx ou pillbox_panel_xxx
Du coup, impossible d’une part d’identifier le contexte du filtre et d’autre part de récupérer le rowId de l’objet parent qui présente la pillbox…
Bon, j’ai pu contourner le problème avec un truc tellement crade que je n’ose pas le qualifier de “solution de contournement”:
Je positionne un paramètre de session dans l’initUpdate de mon formulaire “parent” avec le rowId (du parent) qui présente la pillbox et je le consomme en aval dans le hook preSearch en “intuitant le contexte” via une exception pour analyser la stack trace (je pense avoir trouvé une combinaison de classes/méthodes dans la stack qui serait spécifique à l’instanciation du preSearch lié à la pillbox…) avec une bonne alerte “DEBT/UGLY” dans les logs pour ne pas oublier de résorber tout ça asap…
Après analyse du besoin et de ce que fait Simplicité :
L’appel à l’affichage sur l’instance “tmp” avec un filtre sur le row_id 'in (liste des ids…)" se fait sans parent context car cela est inutile : ce search sert uniquement à récupérer les clés fonctionnelles des objets liés à afficher dans la pillbox.
On va cependant ajouter le contexte du parent et utiliser une instance spécifique “pillbox_” dans la prochaine version au cas où (pour afficher une clé fonctionnelle différente par exemple). Mais je pense qu’il ne servait à rien de mettre du code à ce niveau pour filtrer des choses.
L’appel qui sert à sélectionner les objets liés (via loupe de la pillbox) est bien sur l’instance “ref_” de l’objet cible avec le parent object renseigné.
Le code dans preSearch est donc plutôt à faire uniquement sur l’instance “ref”. C’est d’ailleurs étrange d’utiliser ce hook car il sera appelé 2 fois : pour le count et le select de la page.
Pourquoi ne pas mettre le code dans l’initRefSelect en testant le parent et/ou le nom de l’instance ? comme on le fait pour filtrer une sélection de référence.
→ le hook initRefSelect est-il exécuté pour filtrer le contenu de la pillbox lors du rendu dans le formulaire qui la présente ?
Tel que je le connais, ce hook n’est exécuté que pour filtrer la liste présentée lorsque l’utilisateur clique sur la loupe pour associer un nouvel élément (i.e. ajouter dans la pillbox). Hors, j’ai besoin de modifier la règle de filtrage définie dans le preSearch de l’objet lors du rendu des pillbox.
Pour expliciter mon cas d’usage,
les pillbox en question sont rendues dans un contexte de formulaire de “traitement de données personnelles” et représentent les traitements intervenant “en amont” (première pillbox) et “en aval” (deuxième pillbox) de l’activité de traitement courante (le fameux “parent”).
l’utilisateur courant ne peut par défaut visualiser que les activités de traitement de son périmètre d’opérations.
on souhaite dans le cadre de la présentation des flux d’activité “en amont” / “en aval” altérer ce filtre pour rendre visibles les adhérences sans exposer le détail dans les autres contextes (non visible dans les autres listes, accès au formulaire bloqué).
les seules informations accessibles dans les pillbox sont les informations clés permettant aux acteurs des périmètres “en amont” / “en aval” de se mettre d’accord sur ce dont ils parlent.
Merci pour les explications.
Effectivement, si le besoin est de filtrer les NN accessibles en fonction du parent, on est comme dans le cas d’une vue en panel sur laquelle on voudrait ajouter un filtre/search spec.
initList : en général on utilise ce hook pour préparer la liste avant son affichage UI preSearch : toujours appelé avant tout “select” en base pour le count, une liste paginée, un select(id) qui est search sur le row_id…
Si on change le rendering, il faudrait que le filtre par code s’applique aussi.
Du coup pour être plus homogène sur les nommages des instances / API, il faudrait utiliser un nom d’instance panel ou équivalent comme panel_pillbox_<obj>_<fk>, pour que le isPanelInstance() renvoit true + qu’on sache aussi identifier l’instance pillbox.
avec une bonne alerte “DEBT/UGLY” dans les logs pour ne pas oublier de résorber tout ça asap…