refactor: bouquets as pages

[abulte]

Fix ecolabdata/ecospheres#555
Fix ecolabdata/ecospheres#551
Related #633

Migre les bouquets / collections de topics vers le système de "page" générique introduit dans #711 et précédent. Migre aussi tous les sites (sauf simplification) vers le nouveau format.

Les pages présentant des objets sont maintenant complètement configurables. La configuration se fait à deux niveaux :

• le fichier de configuration du site dans l'attribut pages, avec tous les éléments mutualisables quelque soit l'objet manipulé (aujourd'hui, Dataset et Topic)
• le routeur pour :
  • la structure du site (quelles routes et quels templates pour quel objet)
  • les attributs spécifiques à la présentation des Topic

J'ai utilisé ces deux mécanismes plutôt que de tout mettre dans le fichier de conf pour essayer de garder un fichier de configuration gérable (notamment en ne prenant que des attributs qui s'appliquent à tous les objets). Je ne suis convaincu qu'à 80% que c'est la bonne solution.

Voir par exemple ce que donne la configuration / migration du site hackathons a80dba7.

Le formulaire de création / édition d'un Topic est également configurable, notamment la catégorisation (ex thèmes / sous-thèmes).

Régression connue :

• le fil d'Ariane du Topic n'affiche plus la catégorisation. Compliqué à gérer maintenant que c'est complètement configurable, et peut-être pas vital ?

Migrations de données associées :

• ecologie (supprimer chantiers) : migration: remove chantiers tags from bouquets ecolabdata/ecospheres-scripts#19
• logistique (supprimer sous-catégorie) : migration: remove logistique subtheme tags ecolabdata/ecospheres-scripts#21
• defis : ajout des tags par saison migration: defis tags ecolabdata/ecospheres-scripts#20 (fait sans --move)

[Copilot]

Copilot reviewed 37 out of 37 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (5)

src/model/config.ts:52

• Allowing null for the 'child' field may require updating related validation or usage in the codebase. Ensure that all consumers of PageFilterConf correctly handle null values.

child: string | null

src/components/topics/TopicCard.vue:47

• [nitpick] Consider refactoring the useTag calls to support dynamic filter types. This change would improve maintainability by making the logic generic across different filter contexts.

// FIXME: make this generic for all filters, like indicators

src/components/pages/PageFilters.vue:55

• Changing the default from undefined to null for filter values could affect existing filter logic. Please verify that all parts of the application consuming this state are updated accordingly.

filtersState[filter].selectedValue = singleton ?? null

src/components/forms/SelectSpatialGranularity.vue:17

• The updated prop type now allows null values. Ensure that all consumer components are updated to handle a possible null value without errors.

type: String as () => string | null,

src/components/SelectComponent.vue:29

• Changing the prop type to allow null values might affect components expecting a string. Verify that downstream logic correctly handles cases where the defaultOption is null.

type: String as () => string | null,

[abulte]

De ce que je comprends néanmoins, les routes custom sont elles aussi configurées en dures dans les fichiers custom//routes.ts (c'est ici qu'on va indiquer qu'on veut afficher une page de recherche de topics ou de datasets). Je trouve dommage qu'on doive déporter en dehors de la config cela. Cela implique que la configuration du site n'est pas completement autoportante dans le yaml (en dehors des composants custom mais ça ça se comprend).

+1, d'autant que d'après la description de la PR @abulte tu ne sembles pas non plus convaincu du choix.

Indeed. Je ne suis pas totalement convaincu, mais la conf du routeur a l'avantage de poser une colonne vertébrale typée et de gérer élégamment les composants custom. J'ai vraiment peur de faire une conf trop "puissante" qui va devenir difficile à maintenir, notamment en mélangeant des spécificités des pages Topic et Dataset (et Dataservice demain).

Peut-être qu'on peut partir sur cette solution un peu hybride dans un premier temps et planifier de basculer plus de choses dans la configuration progressivement. Une validation du schéma de la conf va être rapidement indispensable. Ca peut aussi se faire en même temps que le chantier de sortie des configurations des verticales du repo.