Closed sguillaume closed 7 months ago
Info complémentaire fournie par @sguillaume : Ca reviendrait à l’on sépare l'information en 2 tables distinctes. Une qui serait remplie automatiquement et modifiée par les scripts. L’autre qui serait remplie en ligne ("manuellement") à partir de l’éditeur.
De la sorte, il y aurait
Pour le moyen / long terme : piste de réflexion : créer un identifiant (stable et pérenne, ça va de soi) pour chaque corpus, "une fois pour toutes". Ajout d'un champ ("clef unique inamovible") qui ne changera jamais (seule modif possible : suppression). Récupéré en dur (fourni par @sguillaume).
Pour l'instant, tout s'organise autour du nom de langue.
Ce qui bloque pour l'instant la mise en oeuvre de cette proposition : l'identifiant stable & pérenne devrait figurer dans les métadonnées des documents, ce qui implique une modification dans Cocoon, dont les métadonnées sont définies précisément et ne comportent pas actuellement de tel identifiant.
Choix : utiliser le champ subject
, déjà présent dans les métadonnées de Cocoon.
Est ce qu'on pourrait mettre une valeur par défaut vide [] dans le champ "media" de la table corpus_description de la BDD ?
Sinon tout est ok !
Il faudrait mettre dans une table à part toutes les informations concernant la page langue (texte et images). Pour l'instant ces informations sont dans la table "corpus" et cela concerne les champs "descrpition_html" et "media".
Il faudrait créer une table "description_langue" par exemple qui contiendrait les champs "description_html" et "media".
Ca évitera les suppressions de contenu car ce sont les 2 seuls champs de la table "corpus" qui ne sont pas remplis par le script qui gère cette table.