# Analyse de compatibilite SAO / AG Grid

## Objectif

Evaluer si la vue `tree` de SAO peut etre rendue compatible avec une grille open source gratuite, en particulier AG Grid Community, sans React, en JavaScript pur.

## Conclusion courte

Oui, c'est faisable, mais pas comme un simple remplacement visuel de `<table>` par AG Grid.

La vue `tree` actuelle de SAO embarque a la fois:

- le rendu HTML du tableau
- la logique de selection
- l'expansion arborescente
- l'edition inline
- des widgets de cellule lies aux champs Tryton
- le tri
- les colonnes optionnelles
- les boutons d'action
- le drag-and-drop
- les chargements asynchrones de champs

La bonne approche est donc de creer une couche d'adaptation entre:

- le modele Tryton/SAO existant
- et un moteur de rendu "grid"

Autrement dit: il faut decoupler `Sao.View.Tree` de son rendu DOM actuel, puis brancher AG Grid comme renderer alternatif.

## Ce que fait aujourd'hui la vue tree

### 1. Parsing XML des colonnes

La vue `tree` est construite depuis le XML Tryton via `Sao.View.TreeXMLViewParser`, qui instancie des colonnes specialisees selon `attributes.widget`.

References:

- `tryton-sao.js:21678` `Sao.View.TreeXMLViewParser`
- `tryton-sao.js:24807` `Sao.View.TreeXMLViewParser.WIDGETS`

Implication:

- la definition des colonnes est deja structuree
- c'est un bon point d'entree pour produire des `columnDefs` AG Grid

### 2. La vue Tree est tres couplee au DOM table

`Sao.View.Tree` construit directement:

- `div.tree-container`
- `table`
- `colgroup`
- `thead`
- `tbody`
- `tfoot`

References:

- `tryton-sao.js:21755`
- `tryton-sao.js:21796`
- `tryton-sao.js:21803`
- `tryton-sao.js:21810`
- `tryton-sao.js:21908`

Implication:

- aujourd'hui, `Tree` n'est pas un controleur de donnees avec un renderer interchangeable
- c'est deja le renderer

### 3. Les lignes encapsulent elles aussi rendu + comportement

`Sao.View.Tree.Row` construit chaque `<tr>` et tous les `<td>`, gere les clics, doubles clics, la selection, l'expansion, et le rendu cellule par cellule.

References:

- `tryton-sao.js:23219` `Sao.View.Tree.Row`
- `tryton-sao.js:23270` `_construct`
- `tryton-sao.js:23378` `redraw`
- `tryton-sao.js:23528` `toggle_row`
- `tryton-sao.js:23536` `expand_row`
- `tryton-sao.js:23575` `expand_children`

Implication:

- remplacer seulement `table` ne suffit pas
- il faut aussi contourner ou remplacer `Row`

### 4. Le rendu cellule depend fortement des classes Column

Chaque type de colonne sait:

- charger les donnees au besoin
- formatter la valeur
- masquer selon l'etat du champ
- ouvrir des liens Tryton
- afficher des icones/prefixes/suffixes
- gerer des actions particuliere

References:

- `tryton-sao.js:24089` `Sao.View.Tree.CharColumn`
- `tryton-sao.js:24204` `BooleanColumn`
- `tryton-sao.js:24239` `Many2OneColumn`
- `tryton-sao.js:24365` `SelectionColumn`
- `tryton-sao.js:24630` `BinaryColumn`
- `tryton-sao.js:24755` `ButtonColumn`

Implication:

- ces classes sont reutilisables
- mais aujourd'hui elles renvoient surtout du DOM jQuery, pas des objets de configuration AG Grid

### 5. L'edition inline repose sur les widgets Form existants

L'edition tree editable utilise `Sao.View.EditableTree.*`, qui reutilise les widgets formulaire SAO dans les cellules.

References:

- `tryton-sao.js:23737` `Sao.View.Tree.RowEditable`
- `tryton-sao.js:24834` `Sao.View.EditableTree`

Implication:

- c'est une excellente nouvelle pour un POC
- on peut probablement injecter ces widgets dans des `cellEditor` / `cellRenderer` AG Grid custom
- mais il faudra un pont entre le cycle de vie AG Grid et le cycle de vie jQuery/SAO

## Fonctionnalites compatibles assez directement

### Faisable avec une couche d'adaptation raisonnable

- affichage tabulaire
- tri simple sur colonne
- affichage/masquage de colonnes
- selection simple ou multiple
- rendu des types de base: texte, nombre, booleen, date, selection
- boutons de ligne
- copier les lignes selectionnees

Pourquoi:

- SAO a deja les meta-donnees de colonnes
- AG Grid sait tres bien rendre et mettre a jour ces cas

## Fonctionnalites plus sensibles

### 1. Arborescence

SAO gere le mode arbre via `children_field`, expansion paresseuse et chemins de lignes.

References:

- `tryton-sao.js:21836`
- `tryton-sao.js:23479`
- `tryton-sao.js:23575`

Risque:

- il faut mapper cela soit sur le mode tree data AG Grid, soit sur un flattening manuel
- le comportement exact Tryton devra etre conserve, surtout avec chargement lazy

### 2. Edition inline riche

Le flux actuel depend de:

- validation Tryton
- focus clavier
- navigation tab/up/down/enter
- creation de nouvelle ligne a la volee
- sauvegarde conditionnelle

References:

- `tryton-sao.js:23122` `save_row`
- `tryton-sao.js:23163` `edit_row`
- `tryton-sao.js:23893` `key_press`

Risque:

- AG Grid a son propre cycle d'edition
- si on force trop AG Grid, on peut casser le comportement SAO historique

### 3. Chargement asynchrone champ par champ

Le rendu actuel charge les champs a la demande:

- `record.load(...)`
- puis rendu de cellule

References:

- `tryton-sao.js:23204`
- `tryton-sao.js:24120`
- `tryton-sao.js:24681`

Risque:

- AG Grid prefere un modele de `rowData` deja exploitable
- il faudra soit pre-hydrater les lignes, soit supporter des renderers asynchrones

### 4. Drag-and-drop

Le drag-and-drop actuel est tres metier:

- reordonnancement
- changement de parent
- mise a jour des groupes Tryton
- sequence

References:

- `tryton-sao.js:22193` `_add_drag_n_drop`
- `tryton-sao.js:22229` `drag_data_received`

Risque:

- il vaut mieux le repousser a une phase 2

### 5. Sommes de colonnes

Les aggregats sont calcules cote SAO avec prise en compte de la selection.

References:

- `tryton-sao.js:23000`
- `tryton-sao.js:22799`

Risque:

- simple a refaire
- mais il faut decider si l'on garde le footer SAO ou si l'on utilise un footer AG Grid

## Niveau de couplage actuel

Le couplage le plus fort est ici:

1. `Tree` construit la structure HTML complete
2. `Row` construit la structure HTML de chaque ligne
3. `Column.render()` renvoie des fragments DOM jQuery
4. `EditableTree` suppose une presence directe dans le DOM de la cellule

Donc:

- brancher AG Grid directement dans `Sao.View.Tree` sans abstraction serait fragile
- mieux vaut introduire une interface de rendu

## Architecture recommandee

## Option A: remplacement direct de `Sao.View.Tree`

Creer `Sao.View.AGGridTree` qui:

- reutilise `TreeXMLViewParser`
- produit des `columnDefs`
- produit des `rowData`
- delegue a AG Grid pour le rendu
- conserve les appels metier SAO sur `screen`, `record`, `field`

Avantages:

- architecture propre
- bon potentiel a long terme

Inconvenients:

- investissement initial important
- beaucoup de points de compatibilite a reproduire

Verdict:

- meilleur choix si vous voulez un vrai basculement progressif vers une grid moderne

## Option B: mode hybride avec adaptateur de cellules

Conserver `Sao.View.Tree` comme source de verite fonctionnelle, mais:

- remplacer le rendu des lignes par AG Grid
- encapsuler les `Column.render()` existants dans des `cellRenderer`
- encapsuler `EditableTree.*` dans des `cellEditor`

Avantages:

- permet un POC plus vite
- reutilise plus de logique existante

Inconvenients:

- couche d'adaptation plus complexe
- risque de double logique DOM

Verdict:

- meilleur choix pour prouver la faisabilite rapidement

## Option C: simple relooking du tableau actuel

Ne pas utiliser AG Grid, seulement moderniser la table SAO actuelle.

Verdict:

- utile pour du cosmetique
- ne repond pas a l'objectif

## Recommandation concrete

Je recommande une strategie en 3 phases.

### Phase 1: abstraction minimale

Introduire une couche d'adaptation dans SAO:

- `TreeDataAdapter`
- `TreeColumnAdapter`
- `TreeSelectionAdapter`

But:

- separer les donnees et comportements du rendu HTML actuel

### Phase 2: POC AG Grid Community

Cibler uniquement:

- vue tree non hierarchique
- non editable dans un premier temps
- tri
- selection
- affichage/masquage colonnes
- boutons simples
- rendu texte/nombre/date/booleen/selection

Ne pas viser tout de suite:

- tree data
- drag-and-drop
- edition inline riche
- aggregats complexes

### Phase 3: extension progressive

Ajouter ensuite:

- edition inline
- tree data
- aggregates
- drag-and-drop
- compatibilite complete des widgets speciaux

## POC minimal realiste

Le plus petit POC utile serait:

1. Ajouter AG Grid Community dans `index.html`
2. Introduire une option de feature flag, par exemple:
   - `Sao.config.use_ag_grid`
3. Si activée et si la vue est `tree` sans `children_field` et sans `editable`:
   - construire une vue AG Grid
4. Mapper les colonnes SAO vers `columnDefs`
5. Mapper `screen.group` vers `rowData`
6. Reconnecter:
   - clic ligne -> `screen.current_record`
   - double clic -> `screen.row_activate()`
   - tri -> `screen.order` puis `screen.search_filter(...)`

## Mapping propose

### Colonnes SAO -> AG Grid

- `attributes.name` -> `field`
- `attributes.string` -> `headerName`
- `column.sortable` -> `sortable`
- `column.attributes.width` -> `width`
- `column.attributes.readonly` -> `editable: false`
- `column.render(...)` -> `cellRenderer`

### Lignes SAO -> AG Grid

Chaque ligne doit garder:

- le `record` Tryton original
- un `id`
- des valeurs calculees affichables

Exemple de forme:

```js
{
  __record: record,
  __id: record.id,
  customer: "...",
  amount: "...",
  state: "..."
}
```

Important:

- ne pas perdre la reference vers `record`, car toute la logique SAO en depend

## Points d'attention AG Grid

D'apres la documentation officielle AG Grid:

- AG Grid Community existe bien en JavaScript pur
- elle peut etre instanciee sans React avec `agGrid.createGrid(...)`
- elle peut etre chargee par bundle/CDN

Sources:

- https://www.ag-grid.com/javascript-data-grid/getting-started/
- https://www.ag-grid.com/javascript-data-grid/installation/

Inference:

- techniquement, votre environnement SAO charge deja des librairies JS globales via `index.html`, donc l'integration sans React est coherent avec l'architecture actuelle

## Risques principaux

### Risque 1: regressions fonctionnelles

Le danger n'est pas le rendu brut, mais les details de comportement Tryton:

- selection exacte
- edition
- navigation clavier
- chargement lazy
- etats invisibles/readonly

### Risque 2: dette de double implementation

Pendant la transition, vous aurez probablement:

- la vue tree legacy
- la vue tree AG Grid

Il faut donc mutualiser au plus vite:

- les colonnes
- l'acces aux valeurs
- la selection

### Risque 3: AG Grid Community vs besoins reels

Certaines fonctions avancees existent surtout en Enterprise selon les versions et editions.

A verifier au moment du POC, fonctionnalite par fonctionnalite, sans supposer que tout le comportement tree legacy est couvert nativement.

## Estimation honnete

### Faisabilite

- POC non editable, liste plate: elevee
- grille utilisable sur plusieurs vues simples: bonne
- compatibilite complete avec toutes les vues tree SAO: moyenne a difficile

### Cout relatif

- POC: faible a moyen
- integration propre: moyen
- remplacement complet: eleve

## Recommendation finale

Oui, il est pertinent de tenter AG Grid Community en JavaScript pur, mais il faut:

- commencer par les vues tree plates
- introduire un adaptateur plutot qu'un remplacement brutal
- traiter l'edition inline et l'arborescence dans un second temps

Le meilleur prochain pas est de realiser un POC isole sur:

- une vue tree non editable
- sans `children_field`
- avec 3 a 5 types de colonnes
- selection + tri + double-clic ouverture

Si ce POC marche bien, on pourra ensuite brancher l'edition et les widgets complexes.