Conception des chaînes éditoriales

Les proxys de partage sont conçus pour mutualiser des contenus entre pairs. Par exemple, ce type de proxy peut être utilisé par des enseignants souhaitant partager des modules pédagogiques.

La fonction de proxy permet ici de faire la médiation sur des contenus théoriquement identiques entre deux projets éditoriaux différents. Malgré la volonté éditoriale de partager les contenus par transclusion, la dynamique des différents projets éditoriaux peut mettre les fragments proxiés en tension. Concrètement, imaginons deux enseignants travaillant dans la même discipline. L'enseignant A peut proposer à l'enseignant B de réutiliser ses contenus. À l'usage, l'enseignant B souhaite modifier ces contenus afin de mieux les adapter à sa pédagogie. Dans ce contexte, il n'est pas certain que l'enseignant A souhaite récupérer les mises à jour de l'enseignant B. Le principe du proxy de partage permet d'appliquer le principe de surcharge automatique des proxys et de permettre aux deux enseignants de contrôler le versement de modification, depuis l'atelier premier vers l'atelier second ou l'inverse.

À l'initialisation d'un proxy de partage, les fragments proxiés depuis l'atelier premier sont classiquement rendus disponibles dans l'atelier second comme illustré sur la figure 86.

Sur la figure 91, les deux enseignants ont maintenu leurs contenus. Les fragments modifiés dans l'atelier premier sont marqués en vert et ceux modifiés dans l'atelier second sont marqués en violet. Il est à noter que dans le cas de proxys de partage, le système de dérivation automatique fonctionne dans les deux sens : quant un fragment est modifié dans l'atelier second et quand un fragment est modifié dans l'atelier premier. Ainsi, dans l'illustration suivante, le fragment X7 est vert car modifié dans l'atelier premier et un fragment X7', orange car identique au contenu initial, est exploité dans l'atelier second.

Le principe de surcharge automatique fonctionne dans les deux sens. Par conséquent, les deux ateliers doivent nécessairement proposer un système d'état des fragments proxiés afin de contrôler les surcharges. Cinq différents états peuvent être différenciés :

• synchrone : les fragments de l'atelier local (premier ou second) et distant (l'atelier complémentaire, second ou premier) sont identiques ;

• surcharge locale : une modification du fragment de l'atelier local a provoqué une sortie de l'état synchrone ;

• Surcharge locale validée : la modification locale est validée, une mise à jour du contenu est proposée dans l'atelier distant ;

• surcharge distante : le fragment distant a été modifié et validé, une mise à jour est disponible dans l'atelier local ;

• en conflit : une surcharge locale est en conflit avec une mise à jour disponible depuis l'atelier distant.

Le tableau suivant recense les états des différents fragments proxiés au sein du graphe illustré précédemment.

Le versement des modifications depuis un atelier vers l'autre s'effectue en deux étapes. Lorsqu'un rédacteur fait une modification, il dispose de la possibilité de valider sa modification via les menus contextuels. Cette validation entraîne un changement d'état du fragment local (qui passe en surcharge locale validée) et informe le rédacteur de l'atelier distant par le changement d'état du fragment correspondant (qui passe soit de synchrone à surcharge distante, soit de surcharge locale validée ou non à l'état en conflit).

Lorsqu'un fragment est en état surcharge distante, le rédacteur a la possibilité de déclencher une mise à jour par le menu contextuel du fragment.

La gestion des fragments en conflit est gérée au cas par cas en comparant les différences entre les fragments locaux et distants.