Bonjour,
Afin de filtrer une liste d’objet depuis un formulaire je voudrais implémenter le hook preSearch seulement lors de mes tests je remarque que pour filtrer une liste ce hook est appelé 2 fois.
Comment je peux m’y prendre pour définir mes searchSpec une seul fois dans le bon appel ?
Merci par avance.
Déjà positionner la search spec (= filtrage “dur” niveau SQL) est en général une chose “statique” (= par paramétrage en dur ou par du code dans le postLoad). Pour faire des recherches simples c’est plutôt des filtres d’attributs qu’il faut positionner. Il y a des syntaxes avancées pour les recherches complexes, cf. https://docs.simplicite.io/documentation/04-ui/search-syntax.md
Mais bon, si utiliser des filtres d’attributs simples ou complxes ne suffit toujours pas dans votre cas veillez à utiliser l’additional search spec en le positionnant via setAdditionalSearchSpec(...) dans le preSearch et en le remettant à vide dans le postSearch (en le settant à null) sinon vous aurez des comportement “inattendus”.
Et attention à bien utiliser les alias de tables du SQL généré au risque de faire planter les requêtes à cause d’éventuelles ambiguïtés de nommages.
Sinon les pre/postSearch sont appelés 2 fois sur l’affichage des listes de la UI => une première fois pour le count (non paginé), une deuxième fois pour le search paginé, c’est normal.
Attention le postSearch n’est pas appelé lors du count, ce hook prend en paramètre des lignes et sert uniquement à (re)calculer des colonnes, par contre il est bien appelé lors de la recherche de la page.
Il y a aussi l’initList qui peut servir avant recherche (initList/preSearch/search/postSearch).
Il ne faut pas que le nombre d’appels à un hook soit problématique dans votre algorithme / filtrage.
Sur une liste groupée (avec des grouby-by sur des champs) le nombre d’appels aux hooks sera encore plus important.
De quoi dépend votre filtre pour ne pas supporter 2 appels successifs ?
Vous pouvez tester que le filtre est présent (get/setAdditionalSearchSpec sur un champ) pour ne pas le recalculer si déjà présent + le supprimer au postSearch, car l’utilisateur n’y a pas accès sur la UI (alors qu’il voit un setFilter).
Merci pour vos réponses,
En fait je ne voulais pas utiliser les filtres car ils apparaissent dans le tableau et je veux éviter ça.
Pour le moment je suis entrain de concevoir ma solution donc je n’ai pas vraiment rencontré de problème mais comme je veux passer par des specSearch je me demandais si ajouter une meme specSearch 2 fois de suite n’allait pas me poser des soucis.
en fait c’est le but recherché donc tant mieux 
@Francois est-ce que initList serait plus indiqué pour répondre a mon besoin ?
Bonjour,
La search spec peut être positionnée une seule fois par instance d’objet par rapport aux droits utilisateur et au type d’instance, il est préférable de la positionner dans le postLoad qui lui est bien appelé une seule fois par instance :
public void postLoad() {
// liste fille (panel d'un objet parent) d'un groupe
if (isPanelInstance() && getGrant().hasResponsibility("ONE_GROUP"))
setSearchSpec("t.my_field like 'ABC%' and ...");
// Liste principale (accès par menu) d'un autre groupe
else if (isMainInstance() && getGrant().hasResponsibility("OTHER_GROUP"))
setSearchSpec("t.my_field = 'value' or ...");
}
C’est pour cela qu’il faut savoir de quoi dépend votre filtrage pour savoir où le mettre au mieux.
Les autres hooks comme initList ou initRefSelect ou preSearch servent plutôt quand on veut filtrer une liste fille (appelée instance panel) par rapport au contexte/valeurs de l’objet parent affiché, dans ce cas il faut changer le filtre à chaque recherche en testant la présence d’un getParentObject().
PS: bien que ça ne soit plus le sujet de ce post (puisqu’on parle désormais ici de positionner des search specs statiques dans le postLoad), je précise qu’en version 5 on a ajouté un nouveau hook preCount qui est appelé à la place du preSearch dans le contexte du count. Je précise que l’implémentation par défaut de ce hook preCount consiste à appeler le preSearch afin de ne pas induire de changement par rapport à ce qu’il se faisait jusqu’ici.