Tout le reste de la refonte est codé. Il manque une seule chose, et c'est la même dans les deux écrans : poser un point ou une zone sur la carte de l'écran, au lieu d'ouvrir une carte dans une modale ouverte depuis une modale.
C'est le geste le plus contraint que l'app propose aujourd'hui, et c'est aussi le plus fréquent sur une section Map.
0,88 × largeur · neuf champs traduits, une image, une catégorie, une liste de contenus.On place un point en voyant les autres — impossible aujourd'hui, alors que c'est la seule chose qui compte quand on répartit des points d'intérêt sur un plan. Et la fiche reste lisible pendant qu'on dessine, donc on sait quel point on est en train de déplacer.
Liste, fiche, canevas. C'est le gabarit B auquel on ajoute une troisième colonne — et le rail droit de l'écran (Habillage, Diffusion) repasse au-dessus, comme annoncé.
MapGeometryPicker, déplacée telle quelle : point, ligne, zone, couleur. Le pied de carte dit ce qu'on modifie et où, pour qu'aucun clic ne soit ambigu.
Un point porte titre, description, site, prix, téléphone, e-mail, horaires, image et catégorie. Les quatre premiers d'un musée sont presque toujours remplis, les cinq autres presque jamais. La fiche montre donc titre, description, catégorie, image, et replie les informations pratiques derrière une ligne qui dit combien sont remplies. Rien n'est retiré, seulement rangé par fréquence d'usage réelle.
Tentant, et je pense que ce serait une erreur en permanence : un point porte neuf champs traduits, une image, une catégorie et une liste de contenus ; la carte n'en porte qu'un seul, la géométrie. Donner en permanence le plus de place au champ qu'on modifie le moins ferait de la saisie — le vrai travail de cet écran — le parent pauvre. Le back-office est un outil de saisie ; la belle carte, le visiteur l'a déjà dans l'app.
En revanche, 300 px ne suffisent pas pour juger d'une répartition de points. Le canevas passe donc à 420 px de haut par défaut, et gagne un bouton « agrandir » qui lui donne toute la largeur : la liste reste en rail étroit, la fiche se replie. Deux moments distincts, deux dispositions — on écrit une fiche, ou on répartit des points, rarement les deux dans la même minute.
Le canevas sait déjà afficher une carte et recevoir un clic. Le point central se règle donc par un mode du canevas, et geoloc_input_container — repris à la coquille standard cette semaine — n'a plus d'appelant sur cet écran. Il reste utile ailleurs tant que d'autres écrans le référencent.
Un événement pose des annotations sur le plan du site plutôt que des points d'intérêt sur une carte. La mécanique ne change pas, le fond de plan si.
Le canevas d'Événement affiche la carte de base choisie dans baseSectionMapId, et les annotations globales se posent dessus, exactement comme les points. Trois différences, et elles sont toutes dans le contenu, pas dans la forme :
| Ce qu'on pose | Gabarit | Pourquoi |
|---|---|---|
| Annotations du plan | C — canevas | Elles ont une position : elles se posent sur le plan, comme les points de Map. Même liste, même fiche, même canevas. |
| Blocs de programme | B — liste | Ils ont une heure de début et de fin, pas une position. Une liste ordonnée suffit — et c'est déjà ce qu'ils sont. |
| Parcours de l'événement | déjà fait | L'éditeur à fenêtre unique est raccordé et reste tel quel. |
Quand aucune carte de base n'est choisie (baseSectionMapId vaut null), le canevas n'a pas de fond. Deux réponses possibles : afficher une carte vide comme sur Map, ou afficher un message qui invite à choisir un plan d'abord. Je propose la seconde — poser des annotations sur un fond qui va changer, c'est du travail à refaire — mais c'est un choix produit, pas technique.
Le canevas n'ajoute pas une brique : il en absorbe quatre.
| Fichier | Sort | Détail |
|---|---|---|
showNewOrUpdateGeoPoint.dart362 lignes | supprimé | Absorbé par la fiche du gabarit C. Ses champs ne changent pas, ils changent de contenant. |
geometry_input_container.dart | supprimé | Le champ qui ouvrait la carte de dessin n'a plus lieu d'être quand la carte est à l'écran. ⚠️ Deux autres appelants à traiter d'abord : etape_fields et showNewOrUpdateEventAgenda. |
map_geometry_picker.dart | déplacé | Le dessin existe déjà et fonctionne. Il sort de son dialogue pour devenir le canevas. C'est le cœur du lot, et c'est du déplacement, pas de l'écriture. |
showNewOrUpdateMapAnnotation.dart182 lignes | supprimé | Même chose côté Événement. |
geoloc_input_container.dart | conservé | Plus d'appelant sur Map, mais il reste référencé ailleurs. On le garde tant qu'il sert. |
Les points d'un Map vivent côté serveur : l'éditeur de collection sait déjà leur parler depuis cette semaine.
MapCanvas est sorti du dialogue : il reçoit une géométrie, la rend modifiable, rend la main à chaque changement, et affiche les autres tracés en fond. MapGeometryPicker n'est plus qu'une coquille autour de lui, pour ses deux appelants restants.showNewOrUpdateGeoPoint, avec le repli des informations pratiques, puis supprimer la modale.GeometryInputContainer.Aucun DTO, aucun endpoint, aucune migration. GeoPointDTO garde ses neuf champs traduits, sa géométrie et sa couleur ; MapDTO garde ses catégories. Le risque est dans le comportement de la carte, pas dans les données — et il est réversible par git.