Partie 13: Définir l’affichage

Partie 13: Définir l’affichage


Aperçu de l’article

Notions clés

Dernière étape de cette méthodologie. Elle concerne l’affichage des informations et les détails visuels qu’elles peuvent présenter. Ainsi on s’attachera ici à définir si l’affichage des informations doit se faire de manière groupée ou distincte.

Feuilles de styles XSL
Modèles d’afficahge

 


Comment les informations sont-elles affichées?

Une fois les pages de la structure identifiées pour l’histoire en cours, nous nous intéressons aux éléments affichables et surtout aux zones où elles doivent s’afficher :

De même, nous distinguons les éléments statiques des éléments dynamiques.

Définition de l'affichage pour "Rechercher un projet"

Un schéma comme celui-ci est un bon moyen de voir immédiatement les éléments à afficher à l’écran. Si vous avez défini correctement les types dans l’étape Décrire l’information, il ne vous reste qu’à confirmer le contenu des zones pour le besoin en cours.

Un point important est aussi d’identifier si l’affichage des éléments se fera de manière groupée ou non. Cela a son importance pour le style d’affichage et les requêtes sous-jacentes.

Dans la zone d’affichages des projets. Tous les types sont mélangés dans l’affichage (« Commerciaux », « Bénévoles », et « Internes »).

Imaginons que pour la liste des projets, il est nécessaire d’afficher dans la zone prévue, tous les types de projets « Commerciaux, internes, et bénévoles » de manière groupée mais avec un style graphique différent pour chacun, comme le montre l’exemple suivant:

Affichage de résultats groupé mais avec un style graphique différent

Il s’agit ici d’une condition posée sur l’affichage des éléments indépendamment de leur définition. Un affichage groupé peut donc impliquer un choix entre plusieurs éléments de type différents et donc un formatage selon une ou plusieurs métadonnées discriminantes.

Gestion de styles d’affichages et conditions dans SharePoint

Pour répondre aux problématiques de regroupement et plus globalement pour le formatage de l’affichage, SharePoint propose plusieurs solutions qui dépendent de la version du produit que vous utilisez. Le composant utilisé pour afficher l’information (i.e. parmi les composants de flux de lecture) imposera aussi ses restrictions.

Les transformations XSLT

Le XSLT est une technologie de transformations de données XML vers un autre format : le HTML (du moins dans SharePoint). Celle-ci est utilisée dans la majeure partie des composants WebParts gérant le flux de lecture dans les versions antérieures à SharePoint 2013 (2007 et 2010).

Principe de la transformation XSLT

Selon ce principe, les données d’une liste SharePoint (ou les résultats d’une requête CAML) seront récupérés sous format XML et transformées en HTML. Le langage XSL permet de contrôler la sortie et de créer des conditions d’affichage selon les données récupérées en XML. On utilisera donc généralement le principe de métadonnée discriminante et d’affichage conditionnel pour gérer le cas présenté ci-dessus.

Voici un exemple en XSL:

Remarque : Vous avez certainement déjà entendu des développeurs pester contre ce langage de manière générale. La raison? Avec les versions 2007 et 2010 de SharePoint (et même encore dans certaines parties de 2013), Microsoft utilise un compilateur XSLT dans sa version 1.0! Il s’agit d’une spécification W3C datant de 1999 et assez contraignante pour les utilisations du Web actuel. Pour information, le reste du monde utilise actuellement la version 2.0 datant de 2007.

Si vous souhaitez en savoir plus sur les possibilités de XSL dans SharePoint, je vous invite à lire les articles suivants, le but ici n’est pas d’entrer dans le détail de la technologie:

Le JavaScript et les gabarits d’affichage

Depuis l’apparition de SharePoint 2013, il existe de nouveaux moyens de gérer des conditions sur l’affichage des éléments. Consciente des besoins récurrents en termes de personnalisations et compte tenu de la technologie vieillissante XSL, Microsoft propose désormais d’utiliser la technologie JavaScript par l’intermédiaire de deux nouveaux concepts :

  • Les gabarits d’affichage (ou en anglais les « Display Templates »)
  • Les types de résultats (ou en anglais les « Result Types »)

Ces nouvelles notions sont directement liées au langage de recherche et aux contraintes qui viennent avec (souvenons-nous de la différence entre la réalité de l’index et celle de SharePoint) dans SharePoint et non au langage de requête structurée comme le CAML. Cela signifie non seulement que ceux-ci ne sont pas utilisables par tous les composants dans SharePoint (même en 2013) mais que dans certains cas, il faudra utiliser la bonne vieille technique du XSL et requêtes CAML pour vos affichages (si par exemple on souhaite un affichage correspondant à la réalité de SharePoint). C’est donc un point à considérer.

Gabarit d’affichage

Un gabarit d’affichage est simplement un modèle graphique pour l’affichage d’informations. Dans SharePoint 2013. On distingue tout de même deux types:

  • Les gabarits fixes : les métadonnées affichées dans ce modèle seront toujours les mêmes (exemple Titre, Date, et Description). Ce genre de gabarit est utilisé dans le composant de résultats de recherche sous 2013.
  • Les gabarits dynamiques : n’importe quelle métadonnée peut être affichée dans ce modèle, le gabarit fournissant uniquement des « emplacements » d’affichage. C’est  notamment ce principe qui est utilisé dans le composant WebPart de requête de contenu de SharePoint (CQWP) et qui, sous 2013, est repris par celui de recherche de contenu (CSWP).

Gestionnaire de conception et gabarit de pages

 

Les types de résultats

Les types de résultats sous SharePoint 2013 sont le pendant des gabarits d’affichage. Ils permettent de lier des conditions d’affichages avec  un style particulier défini dans un gabarit. Ici, les conditions sont basées sur le langage de recherche KQL.

Les types de résultats en SharePoint 2013

Tableau récapitulatif

Voici un tableau récapitulatif qui vous aidera à identifier la meilleure solution pour répondre à vos besoins:

Composants Versions de SharePoint Technologies
WebPart de liste 2007 XSL
2010
2013 JavaScript & XSL
Web part de requête de contenu 2007 XSL
2010
2013
WebPart de résultats de recherche 2007 XSL
2010
2013 JavaScript
Lecteur RSS 2007 XSL
2010
2013
WebPart de recherche de contenu 2013 JavaScript

Conclusion

La méthodologie présentée ici vous permet d’avoir un aperçu des questions génériques qu’il est important de se poser lors de la réalisation d’une analyse complète d’un besoin avec SharePoint.

Je ne le répèterais jamais assez : cette étape prime sur l’implémentation qui ne doit être que le résultat de cette analyse. Si je ne devais vous donner qu’un seul élément à garder à l’esprit, se serait très certainement d’oublier SharePoint deux minutes et vous concentrer sur les fondamentaux.

Restez simple, c’est le meilleur moyen de réussir!


+ There are no comments

Add yours