Best practices with jQuery & SharePoint

Session animée par Eric Harlan & Mark Rackley

Le sommaire de cette session : présentation de jQuery, les avantages de jQuery avec SharePoint, les inconvénients, le déploiement et la sécurité.

On commence la session par rappeler que JQuery est un framework JavaScript, donc exécuté coté client. Il améliore l’expérience utilisateur. Beaucoup de librairies supplémentaires sont disponibles.

Il ne nécessite pas le déploiement d’assemblies et est amené à être utilisé massivement : dans office 365 et dans le futur Windows 8.

D’après nos 2 speakers, Windows 8 utilisera beaucoup de jQuery.

Après avoir rappelé que SharePoint  est un produit offrant beaucoup de possibilités, ils vantent les mérites du duo SharePoint / jQquery.

Quelles compétences sont nécessaires ? Il faut maitriser JavaScript, le css(s’il est utilisé pour du design), xml (si l’on souhaite faire appel à des webservices), caml, caml, caml, et un petit background de développeur.

Petit rappel : Sharepoint + jQuery c’est génial 🙂

On ne parvient pas à faire ce que l’on souhaite ? jQuery est là ! Certaines fonctionnalités peuvent être mises en place en 2 jours au lieu de 3 semaines.

Après toutes ces éloges, on évoque les inconvénients.

Pour commencer, on a tendance à récupérer des bouts de code sur internet et à les utiliser sans vraiment se poser de questions. Attention ! Il faut prendre la peine de comprendre  le code et de pousser les tests !

Il est facile de blâmer le bloggeur qui a posté cette fonction sur le net mais il faut garder à l’esprit que le contexte d’utilisation nécessite toujours des ajustements.

Autre problème de jQuery, le débogage. On nous recommande l’utilisation de Firebug ou de IE Developer Tools.

On aborde ensuite la récupération des données depuis SharePoint avec l’appel aux Web services.

Le risque quand on charge les données c’est qu’on ne connait pas la configuration du poste client. Les performances sont donc variables d’un poste à l’autre.

Il est important de tester plusieurs navigateurs. Et oui, tout comme le css, le JavaScript réagit différemment d’un navigateur à l’autre.

Le code utilisé pour charger des données doit être robuste et éviter d’envoyer des requêtes trop complexes ou mal formatées (mauvaise date par exemple) à notre serveur.

Pour mettre ça en évidence, nous avons droit à une démo d’appel à un web service pour récupérer les items d’une liste. On lit les items de la liste en boucle et, effectivement, le cpu du serveur atteint les 100% d’utilisation !

On aborde ensuite la problématique de déploiement et les best practices.

Il n’y a en fait pas vraiment de best practices ou de guidelines car ça dépende vraiment du contexte.

Il existe plusieurs méthodes de déploiement

On peut déployer un wsp qui va copier les .js sur le file system du serveur ou bien copier les .js dans un dossier SharePoint (pour office 365 par exemple)

Les avantages du déploiement dans une bibliothèque : modification du fichier facile, on peut voir les modifications du fichier grâce aux métadonnées, on peur revenir en arrière grâce au versioning. Par contre, on a moins de contrôle dessus.

L’activation du versioning est essentielle !

On peut également utiliser un ScriptLink dans la MastePage ou des delegate controls. On peut alors s’assurer le script n’est chargé qu’une fois et au bon endroit. Par contre l’utilisation de Visual Studio est obligatoire dans ce cas.

Autre possibilité, utiliser la WebPart content editor. C’est facile et rapide mais ça peut être dangereux.

Pour finir, on peut charger le jQuery dans la page en utilisant un custom action. Et ça marche avec une solution Sandbox.

Ce qu’il ne faut surtout pas faire : ajouter le script direct dans la MasterPage.

C’est dur à maintenir et ça nécessite des modifications dans Visual Studio.

Concernant la sécurité,  c’est le compte de l’utilisateur courant qui est utilisé. On ne peut pas élever les privilèges !

Petit conseil, il ne faut pas abuser du DOM, parser la page c’est lourd !

Retour à la démo…

On charge une drop down en jQuery en insérant 500 fois un item (durée : 474ms).

Autre test, on crée les 500 éléments DOM d’abord et on les insère qu’une seule fois (durée : 44ms).

Effectivement c’est mieux.

Nous avons droit à d’autres conseils : ne pas exagérer l’utilisation de jQuery (pour remplacer le css par exemple), minimifier les fichiers, utiliser du caml quand on requête des listes pour éviter de remonter trop de lignes, penser à mettre à jour jQuery (après avoir testé !).

On peut utiliser le CMOS (Client Object Model Service) présent dans sp.js ou les Web services qui sont similaires dans SharePoint 2007, 2010 et Office 365.

On passe à une nouvelle démo pour montrer les possibilités graphiques de jQuery, l’utilisation du CMOS.

On voit ensuite la construction d’objet html en JavaScript que l’on peut réutiliser ou l’on veut (dans une fenêtre modale, dans la page, dans des onglets, …). On utilise des templates de code html dans lesquels on insère les données.

On peut, par exemple, utiliser un template différent en fonction d’une des métadonnées de l’item.

Un autre exemple nous montre l’utilisation de jQuery et de Bing.

Pour reprendre leurs termes, c’est du développement « fast food » à bon, pas cher, rapide mais il ne faut pas en abuser ou on le paie tôt ou tard 🙂

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s