Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Les tableaux peuvent être téléchargés au format zip à différents endroits :

  • directement lors de la navigation,

  • lors du partage par mail ,

  • via un lien de partage externe.

Un tableau peut contenir différents types de resources ( images, vidéos, polices, etc… ) qui peuvent générer différents types de variations ( thumbnail, images ou vidéos réduites, cropées, floutées, etc… ). Afin d'éviter que l’utilisateur se retrouve à devoir faire le choix des variations à récupérer pour chaque ressource de son tableau, on lui propose plutôt des profils de zip permettant de piloter les variations demandées pour chaque ressource: zip des originaux, zips de prévisualitations, etc…. WEDIA est livré avec quelques profils type mais il est possible de les personnaliser par client de deux manières :

  • simple configuration json permettant de choisir la première variation disponible pour un content-type donné

  • profil piloté par code via un script groovy.

Configuration json

Le but est d’associer automatiquement une variation à un content-type. ex : je veux les prévisualisations ( thumbnailBig ) des images ( image/* ).

Cette configuration est faite dans les paramètres du plugin WXM_CART2 : previewProfiles et shareProfiles. Ces deux paramètres ont le même format. Le premier définit les profils de zip pour des personnes connectées à la solution. Le second pour des personnes externes.

Le format est : 

{
  "nom_profil": {
    "content-type": ["variation1", "variation2"],
    "content-type2": ["variation2", "variationN"]
  }, // autre profil
}

Le nom du profil est une clé internationalisable par les bundle du panier. Le content-type peut être spécifique ( ex: image/jpg ) ou faire emploi de joker ( ex : “image/*” ou “*/*” ).

Les content-type doivent être ordonnés par ordre de préférence ( du plus spécifique au moins spécifique ) . Le premier qui correspond l’emporte. ( ex : “image/png” → “image/*” → “*/*” )

La liste des variations doit lister les variations par ordre de préférence : la première variation disponible est utilisée.

Si une ressource ne correspond à aucun content-type ou ne retourne aucune variation, elle est exclue silencieusement du zip.

Configuration par code

La configuration par profil est facile à mettre en place mais peut manquer de souplesse. Elle ne permet pas de règles plus “métier” de sélection des variations, ni de contrôler le nommage des entrées du ficher zip. Pour obtenir cette souplesse, il est possible de créer des profils par code. Pour ajouter un profil de ce type, il suffit d’ajouter un profil ( cf chapitre précédent ) avec le format suivant : 

{
// .. autres profils,
  "profil_custo": {
    "script": "some/path/monProfil.groovy";
    "options": {
      "mon option": "personelle",
      "une autre option": "optionnelle"
    }  
  }
}

script référence un script groovy à l’aide d’un chemin relatif à la san. Si au premier appel à ce profil, le script n’existe pas, un est créé avec un code d’exemple fonctionnel. Il suffit ensuite de le modifier selon ses besoins.

l’entrée “options” permet d’ajouter des paramètres configurables qui sont transmises au script pour adapter son comportement sans modifier son code. L’exemple par défaut décrit quelques cas d’usage comme la récupération de variations; le nommage des entrées, etc… La javadoc associée et utilisable dans le script est disponible directement dans le plugin ( /res/javadoc/index.html )

  • No labels