You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 :
migrer l'ensemble du code lié aux bouquets dans le dossier custom/ecosphere
générifier le fonctionnement des bouquets.
La seconde me parait préférable car :
la générification ne me parait pas complexe
le fonctionnement des bouquets pourrait parfaitement être pertinent pour d'autres verticales (ou au moins donner l'exemple en matiere de création de composant plug and play pouvant être réutilisé par d'autres)
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
retirer les mentions à écosphère dans les noms de propriété. Envisager de faire de écosphére la valeur d'une variable et non un intitulé :
extra : {
universe: ecosphere
informations {
....
}
}
n'isoler que le champ spécifique à la recherche de bouquet dans la base écosphére et le rendre parametrable pour d'autres sources (la démarche est entamée avec l'utilisation du concept "local_available" au lieu de "ecosphere_available")
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.
_il n'y a pas de mention de "ecosphére" dans les composants bouquets
_on peut les parametrer pour les utiliser avec une autre source de donnée que celle d'écosphère
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: