Localisation du JavaScript d’une solution Full Trust

Aug 13, 2014

Introduction

Nous, développeurs SharePoint des anciens temps où régnaient les solutions « full trust » avons bien compris une chose : l’utilisation de JavaScript améliore de loin nos solutions.

En effet cela permet de diminuer la charge des serveurs et de rendre l’expérience utilisateur plus « responsive ».

Mais voilà, lorsque l’on veut afficher des messages dans des langues différentes en fonction de l’utilisateur, comment faire ? En .NET (comprenez côté serveur) c’est assez simple, il suffit d’utiliser des ressources. (voir un de mes billets relatif au sujet)

Solutions pour ASP.NET standard

Le framework asp.net permet déjà une localisation des fichiers JavaScripts, cependant ces méthodologies n’est pas forcément très pratiques compte tenu du cycle de déploiement de SharePoint.

https://msdn.microsoft.com/en-us/library/bb398935.aspx

https://msdn.microsoft.com/en-us/magazine/cc135974.aspx

Une autre méthodologie plus adaptée à SharePoint consiste à faire des dupliquas des fichiers JavaScript et de les déployer dans des sous-dossiers par LCID (1033, 1036…). Cela oblige au pire à dupliquer du code, au mieux à avoir un autre emplacement où l’on gère les ressources. (en plus des resx). (c’est comme ça que SharePoint fonctionne en interne)

ScriptLink.RegisterScriptAfterUI(this.Page, "JSample/Scripts/myscript.min.js", true, true);

C’est le second paramètre à true qui permet de faire ça lors de l’appel du script.

Solution proposée par Microsoft

En continuant de chercher je suis tombé sur ce billet de l’équipe produit SharePoint https://blogs.msdn.com/b/sharepointdev/archive/2012/04/05/how-to-localize-custom-script-resources-in-sharepoint-2010-abhishek-verma.aspx

Ils expliquent que SharePoint contient un handler qui permet d’exposer les ressources situées dans la ruche sous forme de JSON (génial !).

Cependant je ne suis pas hyper fan de la manière dont ils appellent ces ressources car :

  • La manière dont c’est présenté suggérerait de devoir faire du script inline (pas bien)

  • L’appel qu’ils font risque de planter si on est dans une collection de site sur une web app qui n’a pas de collection de site racine

  • Les ressources une fois chargée ne sont pas confinées à un espace de nom ce qui risque de conduire à des conflits avec d’autres composants

  • On ne contrôle pas la séquence de chargement avec l’appel qui est fait, autre risque de conflits

  • Le chargement se fait en même temps que le reste de la page et non de manière asynchrone ce qui dégrade l’expérience utilisateur

Ma solution

Voici la solution que je propose, nous allons faire un chargement de script asynchrone via jquery et le JSOM SharePoint et charger les ressources dans un espace de nom dédié. Cela va nous permettre de nous affranchir de toutes les limitations citées plus haut. Le seul point négatif, il va falloir ajouter jquery si ce n’est pas déjà présent. Ce problème n’en est pas vraiment un puisque depuis plusieurs années déjà les développeurs SharePoint utilisent JQuery au sein de leurs projets.

Vous trouverez l’exemple de code à cette adresse https://github.com/baywet/jsfulltrustlocalize

Github

Puisqu’il faut bien une première fois, j’en profite pour vous annoncer que j’ai créé un compte sur github et que c’est là-bas que je posterai mes exemples de code à partir de maintenant. C’est une plateforme très intéressante.

Le gros point positif ? Si jamais il y a des points d’amélioration dans mes exemples, vous pouvez y participer (ou les autres développeurs présents dans le monde entier).


Edité la dernière fois le 27 May 2021 par Vincent Biret


Tags: