Open edelagnier opened 9 months ago
A noter que la notion de bouquet a été pensée au départ pour être générique, en utilisant ${config.universe.name}:
plutôt que ecospheres:
comme clé dans les extras.
Cela correspond aussi à une bonne pratique dans les gestions des extras sur data.gouv.fr, qui peuvent contenir à peu près n'importe quoi : préfixer les clés avec l'outil / la plateforme responsable de l'extra (e.g. check:
sur une ressource pour tout ce qui est linkchecker/crawler).
Le caractère générique permis ${config.universe.name}:
est visiblement (ctrl+f ecospheres:
) seulement "cassé" par le typage de TopicExtras
introduit par #223 et un oubli dans #168 (ecospheres:
en dur).
Considérant cela, il peut-être possible de revenir à un comportement générique sans démarrer un refactoring trop gros, par exemple en utilisant un type custom EcosphereTopicExtras extends TopicsExtras
.
Demande de refactoring
Job story
Actuellement le fonctionnement des bouquets est fortement lié à ecosphéres (principalement par la présence du mot dans l'intitulé des propriétés telles que "ecospheres:informations").
Deux options :
La seconde me parait préférable car :
Scénario
Utilisateur : Les futures verticales du projet
Quand je souhaite proposer la création de bouquet je veux avoir à disposition des composants génériques pour pouvoir les utiliser directement en changeant simplement leur configuration
Proposition de solution au problème
Alternative
Tout migrer vers le sous-dossier custom
Définition de fini
Listez les éléments qui doivent être réalisés pour que cette fonctionnalité soit considérée comme terminée.