Dans la version 2007 de SharePoint, la List View web part proposait la sélection d’une liste et d’un affichage de la liste choisie. Optionnellement, on pouvait modifier la vue pour par exemple afficher une colonne supplémentaire.

Dans SharePoint 2010, cette web part est remplacée par la XSLT List View Web Part. Celle-ci conserve ces fonctionnalités, mais permet en plus de modifier le rendu HTML grâce à une transformation XSL personnalisable. Ce mécanisme permet de redéfinir entièrement le rendu des données issues d’une liste SharePoint, en ayant le contrôle sur la requête CAML sous-jacente. Un vrai couteau suisse :)

Dans ce billet, nous allons voir comment modifier la requête CAML sous-jacente, comment personnaliser la transformation XSLT qui assure le rendu HTML, et comment déporter cette transformation dans un fichier xslt. En effet, par défaut le XSL customisé est stocké en propriété de la web part, mais il est  possible de l’enregistrer dans un fichier séparé afin de le réutiliser pour plusieurs web parts.

Le tout sera fait avec l’interface web classique et SharePoint Designer.

Créons tout d’abord une liste d’annonces, puis ajoutons la web part correspondante sur la page d’accueil.

A ce stade, la XSLT List View Web part exploite la transformation XSLT “out of the box”. Voyons comment modifier la requête CAML et le rendu avec SharePoint Designer. Pour cela on sélectionne la web part, puis dans l’onglet “Liste” on demande la modification de l’affichage avec SharePoint Designer, comme sur cette capture :

SharePoint Designer s’ouvre alors en modification sur la page courante afin de nous permettre de modifier la définition de la web part. On constate que la requête CAML sous-jacente est embarquée dans la définition de la web part.

Modifions cette requête CAML pour y supprimer les colonnes Attachments et Modified, et ajoutons la colonne Body :

On peut alors enregistrer et constater le changement dans le navigateur :

Cette possibilité existait déjà avec SharePoint 2007. Voyons maintenant comment modifier le rendu HTML en personnalisant la transformation XSLT, ceci étant une nouveauté de la version 2010.

Dans SharePoint Designer, on sélectionne la web part et dans l’onglet « Design » on clique sur « Customize XSLT -> Customize entire view »

La définition de la web part est alors modifiée et contient la transformation XSLT.

Celle-ci est très verbeuse car il s’agit de la transformation native qui permet un affichage dynamique en fonction des colonnes sélectionnées quel que soit la requête CAML sous-jacente. On y trouve aussi des appels à des fonctions javascript qui permettent la multi-sélection, le rafraîchissement automatique Ajax et autres fonctionnalités natives des listes SharePoint.

Nous allons maintenant externaliser cette transformation dans un fichier xslt séparé. Cela permet une édition plus pratique et apporte la possibilité versionner, approuver et surtout de réutiliser la transformation dans plusieurs XSLT List View Web Parts. Cette étape est optionnelle car il est possible de modifier la transformation directement dans la définition de la web part, mais je tenais à mettre en avant cette possibilité dans ce billet.

Copions tout le contenu de la balise <xsl></xsl> dans un fichier CustomAnnonces.xslt, et uploadons ce fichier dans la bibliothèque Style Library du site.

Maintenant que le fichier contenant la transformation XSLT est enregistré dans le site SharePoint, nous devons indiquer à la XSLT List View Web Part l’url du fichier xslt à utiliser. Pour cela, dans le navigateur, on modifie les propriétés de la web part et on spécifie l’url relative serveur du fichier dans le champ « Lien XSL » de la section « Divers ».

A ce stade, on peut travailler dans SharePoint Designer pour modifier la transformation CustomAnnonces.xslt. A chaque modification, on peut enregistrer le fichier et rafraichir son navigateur pour constater le changement.

Il n’est pas toujours nécessaire de conserver les centaines de lignes de la transformation XSLT par défaut. La transformation native dite « schema independant » s’appuie sur la requête CAML (passée en paramètre de la transformation) pour renvoyer un rendu HTML en fonction des colonnes sélectionnées dans l’affichage. Plus d’informations sur cette logique « schema independant » sont disponibles dans ce billet : SharePoint 2010 List View Blog Series: Part 3 – List View Architecture.

Pour l’exemple, je ne veux afficher que le champ titre et le champ body avec un rendu HTML très simple sous forme de balises ul / li, et je n’ai pas besoin de conserver les fonctionnalités natives que sont le filtrage dynamique, la multi sélection, etc.

On peut vider le contenu de la balise principale et redéfinir la transformation comme on le souhaite :

Après enregistrement, voici le résultat dans le navigateur :

Au travers de cet exemple simpliste, nous avons vu comment avec SharePoint Designer :

- Personnaliser la requête CAML sous-jacente d’une XSLT List View Web Part

- Personnaliser la transformation XSLT assurant le rendu HTML

- Externaliser la transformation XSLT dans un fichier séparé

Avec une mise en forme CSS et un peu de JavaScript, les possibilités de cette web part peuvent devenir très intéressantes puisqu’elle permet de répondre à énormément de besoins métiers sans nécessiter le déploiement de code serveur. Cette web part va sans nul doute faire beaucoup parler d’elle dans les mois à venir.

Arnault Nouvel - Winwise