Customiser Share 4.0.c pour nos numéros de versions personnalisés

Poursuite de la série d’articles sur les numéros de version personnalisés avec l’amélioration de l’ergonomie pour Alfresco Share 4.0.c. Pour mémoire, l’objectif reste de n’utiliser que des versions majeures, en utilisant les noms des planètes du système solaire.

Avec Alfresco Share 3.4.d, les améliorations de l’interface graphique concernaient la page de détails du document et la popup de mise à jour.
Avec Alfresco Share 4.0.c, pas besoin de modifier la page de détails qui présente nativement un affichage convenable :

Le détail des versions dans Share 4.0.c n'a pas besoin d'être revu


On retrouve en revanche le problème dans la popup de téléchargement d’une nouvelle version :

Le choix d'une version est superflu


et on constate un problème dans le label de la première version des documents : il est fixé arbitrairement à « 1.0 » au lieu du « Mercure » que nous attendons.

La première version d'un document est toujours labellisée "1.0"

Nous allons étudier l’amélioration de ces deux problèmes dans la suite de ce billet.

Uploader un document sans choisir le label de version

Comme dans le cas de Alfresco Share 3.4.d, il va être possible d’utiliser la surcharge du WebScript /components/upload/flash-upload.
Toutefois, il pourrait être intéressant d’utiliser la nouvelle fonction de « modules » de Share 4.0. L’intérêt des modules est qu’ils peuvent être activés ou désactivés à la volée. En deux mots, les modules permettent de compléter, d’ajouter ou de remplacer des composants de Share.
Dans notre cas, nous allons pouvoir remplacer le composant flash-upload pour un composant custom, pour lequel le choix de la version ne sera plus proposé.

La première chose à faire est de dupliquer entièrement le WebScript /components/upload/flash-upload et d’en modifier le rendu HTML comme vu dans le billet sur Alfresco Share 3.4.d.
La seconde est de créer notre module pour spécifier le remplacement de la région flash-upload par la nôtre. Ceci s’effectue par la création d’un document alfresco/site-data/extensions/custom-version-label.xml avec le contenu suivant :
<extension>
  <modules>
    <module>
      <id>Custom Version Labels</id>
      <components>
        <component>
          <scope>template</scope>
          <region-id>flash-upload</region-id>
          <source-id>document-details</source-id>
          <sub-components>
            <sub-component id="default">
              <url>/torda/components/upload/custom-version-label-flash-ulpoad</url>              
            </sub-component>
          </sub-components>
        </component>
      </components>
    </module>
  </modules>
</extension>

Le point clé est d’utiliser l’id default pour le sous-composant. Cet id permet de spécifier que la région doit être remplacée, plutôt que complétée.

Une fois le module packagé dans un .jar placé dans le dossier WEB-INF/lib et le serveur redémarré, il est possible d’utiliser la console de gestion des modules pour l’activer.

Déploiement de notre module pour Share 4.0.c


Et après cette rapide manipulation, nous disposons d’un affichage conforme à notre souhait :

Le choix de la version a disparu

A titre d’exercice, je vous laisse améliorer le module pour que la même popup soit obtenue lorsque la mise à jour est appelée depuis la liste des documents.

Labelliser correctement les premières versions

Nous l’avons vu plus haut, lorsqu’un nouveau document est créé, le label de version « 1.0 » lui est automatiquement appliqué :

La première version d'un document est toujours labellisée "1.0"


Cette numérotation « arbitraire » est transmise par Alfresco lors de l’appel au webscript doclist-v2. Ce WebScript construit un flux JSON qui décrit chaque nœud de la liste. La « mise en forme » de chaque nœud est confiée à la macro itemLib.itemJSON, définie dans le fichier item.lib.ftl. Cette macro va être également responsable du calcul du label de version :
<#assign version = "1.0">
<#if node.hasAspect("cm:versionable") && node.versionHistory?size != 0><#assign version = node.versionHistory[0].versionLabel></#if>

Qui se traduit par : « si le noeud n’a pas été versionné, son label de version est ’1.0′, sinon son label est celui de sa version la plus récente. »

Maintenant que nous avons identifié le WebScript responsable du « problème », nous pouvons le surcharger pour obtenir le résultat attendu.
La première étape consiste à écrire notre propre item.lib.ftl, admettons custom-item.lib.ftl et de modifier la ligne 3
<#assign version = "1.0">
de la sorte :
<#assign version = "Mercure">
La seconde est la duplication de doclist.get.json.ftl dans le chemin d’extension (alfresco/extension/templates/webscripts/org/alfresco/slingshot/documentlibrary-v2) et la modification de la première ligne :
<#import "item.lib.ftl" as itemLib />
par
<#import "custom-item.lib.ftl" as itemLib />

Après rechargement des WebScripts Alfresco, on peut observer dans Share quelque chose comme :

Le label de version est conforme à notre attente

Nous avons atteint notre but, mais plusieurs remarques doivent être formulées :

  • item.lib.ftl est également utilisé dans le webscript node-v2, il faudra donc également surcharger son rendu JSON pour utiliser custom-item.lib.ftl
  • écrire « Mercure » en dur ne fait pas mieux qu’Alfresco avec son « 1.0 » : étant donné que le calcul du label de version peut différer selon le type de noeud (cf. billet sur la personnalisation des numéros de version), il serait préférable de mettre en place un système plus dynamique. Et ce sera l’objet d’un prochain billet !

Notre exploration des mécanismes des versions Alfresco n’est pas encore terminée ;-)

Cette entrée a été publiée dans Alfresco, Technique, avec comme mot(s)-clef(s) , , , . Vous pouvez la mettre en favoris avec ce permalien.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Protected by WP Anti Spam