Je ne suis pas très fan du système de filtrage de Grist, ça peut marcher pour du filtrage statique, mais sinon c’est trop lourd à utiliser (et en plus il n’y a que de la logique ET).
Donc j’ai développé un widget pour filtrer rapidement une table :
De base, ça affiche toutes les lignes qui contiennent au moins un des mots (suivant la logique OU).
Les sources et les instructions détaillées sont dispo sur Github et un exemple est dispo ici.
Au début s’était un simple système de filtrage, mais bon c’est vite devenu un système avec pas mal d’options telles que : la logique ET, la négation, exactement égal, commence par, les regex ou la sélection de colonnes… Veuillez lire le README sur Githib (en français) pour avoir tous les détails.
Bonjour et merci @varamil pour ce super widget, très utile !
Je ne vois pas d’option pour chercher un mot entier et pas une chaîne de caractères (par exemple faire en sorte que « eau » ramène « eau » mais pas « rideau »). Typiquement la syntaxe des guillemets dans les moteurs de recherche… est-ce qu’il serait envisageable d’ajouter cette option ?
Il faut que je réfléchisse à la question, à chaud je me dis qu’une regex ferait l’affaire en arrière plan, mais ça suppose qu’uniquement des caractères alphanumériques soient utilisés.
Dans le code actuel, je ne localise pas la présence des mots, juste s’ils sont présents, donc je ne peux pas vérifier ce qu’il y a avant ou après.
Je pense avoir quelque chose qui pourrait convenir et j’en ai profité pour améliorer la gestion des espaces.
Le README est à jour, mais voici les changement:
"..." : permet de considérer que tous ce qui est entre les guillemets est un mot (incluant les espaces). ça évite de devoir utiliser les \s moins intuitif
' en début de mot, alors le mot doit apparaître tel quel eau seul et non rideau. Compatible avec ! mais pas avec =, < ou >
Une mise à jour corrigeant un bug important est disponible.
Par erreur j’utilisais les ids de ligne au lieu des index de la table quand je parcourrait les données. Ce qui avait pour conséquence quand des lignes de la table avaient été supprimés de créer des décalages dans les résultats de recherche, et donc de mauvais résultats.
Bravo @Varamil et merci, ce widget me sauve et correspond exactement à ma recherche !!!
Un petit détail … lorsque le résultat s’affiche … la ligne active devient la dernière ligne +1, prêt pour une nouvelle saisie.
Comment serait-il possible que la ligne active soit la première ?
En fait dès qu’une ligne est sélectionnée j’affiche un point correspondant sur une carte, faire une recherche qui matche me permettrait d’afficher automatiquement ce point et donc d’éviter de sélectionner manuellement la ligne résultante.
Comme précisé, c’est un détail car je suis trop satisfait de ce widget; encore merci
Pour l’histoire de la dernière ligne j’avoue je suis un peu surpris, car j’utilise ce widget tous les jours, et j’enrage souvent contre un comportement de grist qui est de toujours sélectionner la première ligne d’une table quand celle ci prend le focus, même si on a scrollé et essayé de sélectionner une autre ligne.
A moins qu’il faille comprendre que c’est le widget lié au widget lié au filtre (pas facile ça), qui ne s’initialise pas suite à l’application du filtre et qu’il faut obligatoirement sélectionner une ligne pour forcer ce rafraîchissement ? Faudrait peut être que je regarde pour forcer un peu les choses…
Merci pour votre retour immédiat.
En effet, le focus est toujours donné au chargement sur le premier enregistrement de la table. Mais dans le cas présent, avec le filtrage par le widget, pour moi, c’est toujours la dernière ligne vide.
génial et super bien documenté, merci du partage !
