Passer à AG grid pour les tableaux de données #41

New Issue

2025-09-27T12:45:50+02:00

ColinMaudry commented

2025-09-27 12:45:50 +02:00

(Migrated from github.com)

Les datatables utilisées actuellement dans decp.info ne seront bientôt plus supportées par Plotly au profit des AG Grids. Ces dernières sont plus puissantes, mais la migration n'est pas simple car j'ai beaucoup personnalisé les datatables, et elles sont utilisées un peu partout dans l'application.

Arguments pour migrer :

utiliser un type de table supporté à long terme par Plotly
pouvoir mettre en oeuvre des outils de filtrage et de manipulation de données plus avancés

Voir :

Les datatables utilisées actuellement dans decp.info ne seront bientôt plus supportées par Plotly au profit des AG Grids. Ces dernières sont plus puissantes, mais la migration n'est pas simple car j'ai beaucoup personnalisé les datatables, et elles sont utilisées un peu partout dans l'application. Arguments pour migrer : - utiliser un type de table supporté à long terme par Plotly - pouvoir mettre en oeuvre des outils de filtrage et de manipulation de données plus avancés Voir : - https://www.ag-grid.com/example/ - https://dash.plotly.com/dash-ag-grid

ColinMaudry commented

2025-09-27 13:12:52 +02:00

(Migrated from github.com)

ColinMaudry commented

2026-07-09 11:43:53 +02:00

(Migrated from github.com)

Ordonnancement (voir #101) : cette migration AG Grid vient après la montée en version Dash 4.x (#101). Les DataTable sont dépréciées et retirées en Dash 5.0, donc échéance ferme avant Dash 5. Le filtrage booléen avancé (#97) pourra s'appuyer sur AG Grid + traduction filterModel → requête DuckDB côté serveur.

Ordonnancement (voir #101) : cette migration AG Grid vient **après** la montée en version Dash 4.x (#101). Les DataTable sont dépréciées et retirées en Dash 5.0, donc échéance ferme avant Dash 5. Le filtrage booléen avancé (#97) pourra s'appuyer sur AG Grid + traduction `filterModel` → requête DuckDB côté serveur.

ColinMaudry commented

2026-07-09 22:38:26 +02:00

(Migrated from github.com)

Décision d'architecture — migration vers Dash AG Grid

Direction validée pour la migration. Résumé des choix structurants.

Objectifs

Préserver les fonctionnalités existantes. Dans un premier temps on conserve l'apparence de base d'AG Grid ; le portage de nos overrides CSS actuels (styles de cellules, polices, etc.) est reporté à un second temps.
Rendre #97 (requêtes booléennes) implémentable et le réserver aux abonnés — l'archi de filtrage est choisie pour ça.

Séquençage

Lot 1 : tableau.py seul (page vitrine, cas le plus complet) — on éprouve le pattern AG Grid + row model + moteur de requête avant de généraliser.
Lot 2 : acheteur.py, titulaire.py, observatoire.py (server-side, périmètre restreint).
Lot 3 : recherche.py, admin/liste.py, figures.make_table (statiques / triviaux).

Row model

Infinite Row Model (server-side) pour tableau.py : correspond au paging/filtre/tri custom actuel sur DuckDB (~1,5 M lignes). AG Grid n'affiche que la page courante et renvoie l'état de filtre/tri à un callback Dash.

Pas de rétro-compatibilité (version majeure)

L'encodage riche d'une vue dans l'URL (?filtres=…&tris=…&colonnes=… en DSL DataTable) est retiré.
Le partage/rappel de vue passe désormais par les vues sauvegardées (abonnés), via URL courte ?vue=<user_id>_<nom> → voir #112.

Moteur de requête : AST booléen canonique → SQL DuckDB

Point-clé : avec le row model server-side, c'est notre callback qui compile le filtre en SQL — AG Grid n'est qu'une grille d'affichage. On ne dépend donc pas de la puissance de filtrage d'AG Grid, mais d'un bon modèle interne.

Modèle canonique = un arbre d'expression booléenne (AST) : AND/OR/NOT + groupement, feuilles = colonne contains valeur (réutilise tokenize_text_filter : insensible casse/accents, wildcards *, phrases +).
Compilateur unique AST → SQL DuckDB paramétré.
Deux producteurs alimentent le même AST :
1. Mode simple (gratuit) : les filtres de colonne AG Grid → feuilles combinées en AND (comportement actuel préservé).
2. Mode avancé (#97, abonnés) : un champ de requête texte inter-colonnes, ex. (béton OR ciment) AND brique AND NOT démolition, parsé vers le même AST.
Les vues sauvegardées stockent l'AST (JSON), indépendant de l'UI.

#97 — approche retenue

Parseur texte maison → AST, syntaxe FR (OR/AND/NOT, parenthèses) telle que décrite dans #97.
Inter-colonnes d'emblée (couvre « département acheteur OU titulaire »).
Pas d'AG Grid Enterprise : son « Advanced Filter » est un builder visuel sous licence payante, alors que #97 décrit une saisie texte, et qu'en server-side on compilerait de toute façon son modèle en SQL nous-mêmes.

Liens

#112 (partage de vues abonnés par URL courte)
#97 (requêtes booléennes)

## Décision d'architecture — migration vers Dash AG Grid Direction validée pour la migration. Résumé des choix structurants. ### Objectifs 1. **Préserver les fonctionnalités existantes.** Dans un premier temps on **conserve l'apparence de base d'AG Grid** ; le portage de nos overrides CSS actuels (styles de cellules, polices, etc.) est reporté à un second temps. 2. **Rendre #97 (requêtes booléennes) implémentable** et le réserver aux abonnés — l'archi de filtrage est choisie pour ça. ### Séquençage - **Lot 1 : `tableau.py` seul** (page vitrine, cas le plus complet) — on éprouve le pattern AG Grid + row model + moteur de requête avant de généraliser. - Lot 2 : `acheteur.py`, `titulaire.py`, `observatoire.py` (server-side, périmètre restreint). - Lot 3 : `recherche.py`, `admin/liste.py`, `figures.make_table` (statiques / triviaux). ### Row model - **Infinite Row Model (server-side)** pour `tableau.py` : correspond au paging/filtre/tri custom actuel sur DuckDB (~1,5 M lignes). AG Grid n'affiche que la page courante et renvoie l'état de filtre/tri à un callback Dash. ### Pas de rétro-compatibilité (version majeure) - L'encodage riche d'une vue dans l'URL (`?filtres=…&tris=…&colonnes=…` en DSL DataTable) est **retiré**. - Le partage/rappel de vue passe désormais par les **vues sauvegardées (abonnés)**, via URL courte `?vue=<user_id>_<nom>` → voir #112. ### Moteur de requête : AST booléen canonique → SQL DuckDB Point-clé : avec le row model server-side, **c'est notre callback qui compile le filtre en SQL** — AG Grid n'est qu'une **grille d'affichage**. On ne dépend donc pas de la puissance de filtrage d'AG Grid, mais d'un bon modèle interne. - **Modèle canonique** = un **arbre d'expression booléenne (AST)** : `AND`/`OR`/`NOT` + groupement, feuilles = `colonne contains valeur` (réutilise `tokenize_text_filter` : insensible casse/accents, wildcards `*`, phrases `+`). - **Compilateur unique** AST → SQL DuckDB paramétré. - **Deux producteurs** alimentent le même AST : 1. *Mode simple (gratuit)* : les filtres de colonne AG Grid → feuilles combinées en `AND` (comportement actuel préservé). 2. *Mode avancé (#97, abonnés)* : un champ de requête texte inter-colonnes, ex. `(béton OR ciment) AND brique AND NOT démolition`, parsé vers le même AST. - Les **vues sauvegardées** stockent l'AST (JSON), indépendant de l'UI. ### #97 — approche retenue - **Parseur texte maison → AST**, syntaxe FR (`OR`/`AND`/`NOT`, parenthèses) telle que décrite dans #97. - **Inter-colonnes d'emblée** (couvre « département acheteur OU titulaire »). - **Pas d'AG Grid Enterprise** : son « Advanced Filter » est un builder visuel sous licence payante, alors que #97 décrit une saisie *texte*, et qu'en server-side on compilerait de toute façon son modèle en SQL nous-mêmes. ### Liens - #112 (partage de vues abonnés par URL courte) - #97 (requêtes booléennes)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: colin/colibre#41