Objectif des templates
L’objectif des templates est de définir la liste des différents blocs à afficher lors du rendu d’une fiche.
Chaque fiche de métadonnées possède un champ clientTemplateName qui permet de savoir qu’elle template va utiliser. Lorsque ce champ n’est pas renseigné ou lorsque aucun template ne correspond au nom indiqué, le template default est utilisé.
Un template permet d’indiquer:
- Un rendu par défaut.
- Un rendu différent par catalogue. Ainsi, une fiche peut avoir un rendu différent par exemple sur le site de campagne et sur le site du pôle. Cette possibilité est rarement utilisée.
- Si un bloc est éditable ou non. Ceci permet par exemple à une fiche d’être éditable sur le site de campagne et non éditable sur le site du pôle. Cette possibilité est rarement utilisée.
- Des propriétés à passer au bloc
Actuellement, 4 onglets sont disponibles et affichés dans cet ordre:
- metadataTab: Onglet de description générale (Abstract, Extensions spatiales et temporelles…)
- downloadTab: Onglet dédié au téléchargement (Accès à la données, DOI, Data policy…)
- statisticsTab: Onglet dédié aux informations statistiques (Nombre de téléchargement…)
- visualisationTab: Onglet permettant la pré-visualisation du jeu de données (Graphes, Cartes…)
- interoperabilityTab: Onglet affichant les informations relatives à l’interopérabilité (Identifiant de la fiche de métadonnées, …)
Les fiches d’un même projet peuvent donc avoir des templates de métadonnées différents, ce qui n’est pas le cas pour les templates de recherche.
Liste des blocs
La liste des blocs disponibles peut être consultée ici: https://api.sedoo.fr/aeris-cdn-rest/blockrepo/v1_0/list
Documentation
Les blocs communs sont documentés ici: https://api.sedoo.fr/aeris-cdn-rest/documentation/v1_0/aeris-metadata/
Syntaxe des templates
Il existe deux types de syntaxe possible pour un template. Chacune s’exprime en JSON.
Syntaxe explicite
La syntaxe explicite consiste à donner la liste de tous les blocs à afficher dans les différents onglets.
{
"name": "nomDuTemplate",
"templates": {
"default": {
"metadataTab": [
{
"name": "aeris-metadata-title",
"editable": true,
"props": {}
},
{
"name": "aeris-metadata-description",
"editable": true,
"props": {}
},
{
"name": "aeris-metadata-spatial-extents",
"editable": true,
"props": {}
},
{
"name": "aeris-metadata-temporal-extents",
"editable": true,
"props": {}
},
{
"name": "aeris-metadata-site",
"editable": true,
"props": {}
},
{
"name": "aeris-metadata-platforms",
"editable": true,
"props": {}
},
{
"name": "aeris-metadata-instruments",
"editable": true,
"props": {}
},
{
"name": "aeris-metadata-parameters",
"editable": true,
"props": {}
},
{
"name": "aeris-metadata-contacts",
"editable": true,
"props": {}
},
{
"name": "aeris-metadata-process-level",
"editable": true,
"props": {}
},
{
"name": "aeris-metadata-dataset-history",
"editable": true,
"props": {}
},
{
"name": "aeris-metadata-information-links",
"editable": true,
"props": {}
},
{
"name": "aeris-metadata-publications",
"editable": true,
"props": {}
}
],
"downloadTab": [
{
"name": "aeris-metadata-doi",
"editable": true,
"props": {}
},
{
"name": "aeris-metadata-data-access-manager",
"editable": true,
"props": {}
},
{
"name": "aeris-metadata-datapolicy",
"editable": true,
"props": {}
},
{
"name": "aeris-metadata-downloads",
"editable": false,
"props": {
"downloadComponentName": "aeris-metadata-single-file-download"
}
},
{
"name": "aeris-metadata-data-links",
"editable": true,
"props": {}
},
{
"name": "aeris-metadata-formats",
"editable": true,
"props": {}
}
],
"statisticsTab": null,
"visualisationTab": null,
"interoperabilityTab": null
}
}
}
Syntaxe implicite
La syntaxe implicite permet de définir un template par héritage d’un template existant, celui-ci pouvant être lui même un template implicite.
Cette syntaxe comporte de nombreux avantages:
- Les templates sont plus concis et donc plus simples à maintenir
- Ils bénéficient automatiquement des ajouts de nouveaux blocs dans les templates parents.
Elle est donc à privilégier pour un projet en créant un premier template qui va hériter de default et servir de base à tous les templates du projet.
La syntaxe permet:
- D’ajouter un bloc en début/fin d’onglet
- D’ajouter un bloc avant/après un bloc existant
- De supprimer un bloc existant dans le parent
- De modifier le caractère éditable d’un bloc
- D’ajouter des propriétés à des blocs
{
"_class": "relativeMetadataTemplates_v2",
"id": "61668e80c352b3c79f2f083a",
"name": "cdpp",
"parentName": "default",
"metadataTab": [
{
"name": "aeris-metadata-doi",
"editable": true,
"props": {},
"relativePosition": {
"type": "before",
"blocName": "aeris-metadata-description"
}
},
{
"name": "aeris-metadata-monbloc",
"editable": true,
"props": {},
"relativePosition": {
"type": "first",
}
},
{
"name": "aeris-metadata-monAutrebloc",
"editable": true,
"props": {},
"relativePosition": {
"type": "last",
}
},
{
"name": "cdpp-input-block",
"editable": true,
"props": {},
"relativePosition": {
"type": "after",
"blocName": "aeris-metadata-doi"
}
}
],
"downloadTab": [],
"statisticsTab": [],
"visualisationTab": [],
"interoperabilityTab": [],
"deletedBlocs": [
"aeris-metadata-doi",
"aeris-metadata-fair-principle",
"aeris-metadata-link",
"aeris-metadata-catalogue-api",
"aeris-metadata-temporal-extents",
"aeris-metadata-data-access-manager"
],
"editability": {
"aeris-metadata-*": false
},
"properties": {
"cdpp-input-block:toto": "tutu"
}
}
Remarque
Par défaut, l’appel à un template implicite va donner comme réponse la forme explicite résultant de l’interprétation de son contenu.
Exemple: https://api.sedoo.fr/aeris-metadata-template-rest/template/v2/byname/cdpp
Pour visualiser le template implicite, il faut indiquer source=true comme paramètre de la requête.
Exemple: https://api.sedoo.fr/aeris-metadata-template-rest/template/v2/byname/cdpp?source=true
Services Web
Les services web pour gérer les templates sont disponibles ici
Attention
- Il faut utiliser les service « Version 2 »
- Lors de la création d’un template, veillez à ne pas mettre de champi « id » dans le JSON
- Vérifiez bien que le « id » indiqué lors d’un POST est bien celui de votre template, au risque d’écraser un template existant
Les services ne sont pas sécurisés. Les templates ne sont pas versionnés.
Développer des blocs spécifiques à un projet
Il est possible de développer des blocs spécifiques à un projet de manière autonome. Pour ce faire on peut s’inspirer de l’exemple de code disponible ici.
Afin de limiter le nombre de projets, lorsque le nombre de bloc est limité, les blocs spécifiques peuvent être regroupés par thématique au sein d’un seul projet:
Cas du template par défaut
Il existe un template par défaut – default – qui est ramené si le template demandé n’existe pas. Ce template ne doit pas être modifié directement en base. En effet, du fait de son importance dans le catalogue et pour éviter tout risque de corruption involontaire, ce template est recrée à partir du code par le backend à chaque redémarrage.