Closed vbombaerts closed 1 year ago
Est-ce une bonne approche ? Je dirai plutôt oui.
Actuellement on a
Donc il ne manque pas grand chose:
Ce sont des infos en dur dans le Java, qu'il faudrait peut être au moins mettre en config externe (cf. FIELDLIST_RELATED)
Ajout des conditions:
Un petit souci au niveau de l'indexation multilingue. La langue n'est pas spécifiée pour le rapport de qualité (lang
au lieu de langfre
)
Au niveau de la liste des données servies, je trouve qu'il y a confusion du fait de mettre dans la même liste les id des fiches avec les adresses d'accès aux fiches. Il y a une raison ? Ce ne serait pas plus propre de faire un objet par fiche avec [id,adresse] ?
Un petit souci au niveau de l'indexation multilingue. La langue n'est pas spécifiée pour le rapport de qualité (lang au lieu de langfre)
A déployer. En fait y'en avait plusieurs des soucis - surtout dans la mise à jour de liens dans l'éditeur pour les documents qui n'était pas dans la section distribution pour les fiches multilingues (eg. DQ report, Legend). Ca vaut le coup de refaire quelques tests sur ces fonctions.
OK pour la partie related>services. Pas encore testé sur les autres éléments.
Suite à discussion avec l'équipe géoportail, on souhaite récupérer plus d'informations au niveau des services liés à une donnée. L'idée est d'abandonner le catalogue des services dans sa version actuelle et basculer vers l'intégration de certaines informations des services dans la fiche de donnée, par exemple dans un onglet API/services. (Un catalogue spécifique au service pourrait subsister, par exemple sous forme de tableau créé avec les webcomponents)
Les infos qu'on souhaite afficher au niveau de l'onglet API/services d'une donnée sont :
Une approche serait d'ajouter les infos manquantes à celles déjà fournies par l'élément related.service._source Est-ce une bonne approche ?