Partie 10: Définir les points d’accès

Partie 10: Définir les points d’accès


Aperçu de l’article

Notions clés

Les points d’accès représentent les pages utilisées pour afficher l’information. Selon le type d’information à afficher, il existe plusieurs possibilités de pages, chacune répondant à une problématique précise.

Page de publication
Page Wiki
Page de composants WebPart


Selon la répartition effectuée et la circulation de l’information, où se trouvent les points d’accès à l’information et quels types y sont présents?

À cette étape, il s’agit d’identifier les pages qui accéderont à l’information définie à l’étape précédente. En d’autres termes, il s’agit de déterminer où se trouvent les interfaces correspondant aux maquettes de la fonctionnalité dans la structure SharePoint et ceci tenant compte du scénario choisi dans l’étape précédente.

Contexte d’informations et cas d’utilisation

Un point d’accès est typiquement une page Web affichant un ou plusieurs types d’informations.

Le point d’accès est ce qui représente le contexte d’information pour un utilisateur. Par exemple la page « gestion-projet.aspx » correspond à l’espace où un utilisateur X peut rechercher un projet et accéder à l’information dont il a besoin.

On distingue 3 cas de figure pour afficher de l’information :

  • Informations non typées (ou information brute) : du texte simple non attaché à un type particulier (Exemple : un texte de bienvenue)
  • Agrégation de données : Regroupement d’informations provenant de sources de données différentes (un tableau de bord par exemple)
  • Informations typées : Visualisation des informations propres à une instance de type particulier (un élément de liste par exemple)

Dans mon scénario (« Rechercher un projet »), je choisis un unique point d’accès dans une page du même site selon le ou les flux d’informations que je souhaite gérer(un flux de lecture et d’écriture).

Exemple de point d'accès dans une structure SharePoint

Une seule et unique page de gestion de projet permettra aux utilisateurs de rechercher un projet et la liste des documents et personnes associées.

Ce cas de figure représente donc une agrégation de données car plusieurs types vont y être affichés. Il me faudra donc un type de page adapté à ce cas.

Gestion des points d’accès dans SharePoint

Dans SharePoint, les points d’accès à l’information correspondent à des pages mises en forme par des gabarits de pages. Cependant, comme pour les composants de type « WebPart », il existe plusieurs types de pages présentant chacune des spécificités qu’il est important de connaître lors de la phase de conception et couvrant les 3 cas de figure énoncés plus haut.

Informations non typées : Pages wiki

Le premier type de page rencontré dans SharePoint et aussi le plus simple : les pages wiki. Il s’agit tout simplement d’une page éditable directement dans l’interface Web en mode WYSIWYG (« What you see is what you get »). Vous pouvez y positionner de l’information statique et également des composants WebPart là ou vous le souhaitez, la mise en page étant simple (1, 2, 3 colonnes, etc.).

Lors de la conception de solutions dans SharePoint, il  est important de savoir que les pages de type wiki ne tolèrent pas la mise en relation d’informations par l’intermédiaire des mécanismes de connexions de WebPart. Elles sont donc généralement destinées pour de l’information purement statique, brute, dans un mode de flux de lecture et non pour de l’agrégation de données.

Principe des pages Wiki

Notez que pages Wiki sont stockées systématiquement dans la bibliothèque « SitesPages » d’un site SharePoint standard et dans « Pages » pour un site de publication.

Agrégation de données : Page composants WebPart

Les pages de composants WebPart diffèrent des pages de type Wiki car elles ne permettent pas l’édition en mode WYSIWYG directement, mais proposent un « cadre » modulaire configurable pour y placer des composants. Ces pages sont donc particulièrement adaptées pour des connexions entre données et de la visualisation d’informations dynamiques sous forme de tableaux de bord en flux de lecture et écriture, par exemple.

En d’autres termes, elles favorisent l’agrégation et la mise en relation de données.

Principe des pages de composants WebPart

Il est possible d’ajouter du texte statique en complément, en utilisant un composant WebPart  d’éditeur de contenu par exemple, qui lui offrira les fonctionnalités d’édition « live ».

  • Les pages de composants de WebPart peuvent être stockées dans n’importe quelle bibliothèque de documents SharePoint.

Informations typées : Page de publication

La page de publication est le dernier type de page disponible dans SharePoint mais aussi le plus complexe à comprendre car il se distingue aussi bien fonctionnellement que techniquement.

Pour visualiser une information typée dans SharePoint, il existe un moyen de base : le formulaire d’affichage de liste ou de bibliothèque, qui permet d’afficher les métadonnées d’une instance de ce type. Cependant, cet affichage demeure plutôt rudimentaire et ne permet pas d’afficher « proprement » la donnée ni de choisir les métadonnées pertinentes.

Une page de publication représente donc un moyen alternatif aux listes classiques SharePoint pour mieux contrôler l’affichage des informations dans SharePoint.

Ce contrôle s’effectue sur deux points :

  • Cycles d’approbation de publication des informations aux utilisateurs.
  • Contrôle du style graphique par l’intermédiaire de gabarits de pages.

Le dernier point implique qu’une page de publication soit toujours liée à un gabarit de page permettant de contrôler son style d’affichage.

 Notez que les pages de publication ne sont utilisables qu’après activation de fonctionnalités spécifiques liée à l’infrastructure de publication dans SharePoint et résident uniquement dans la bibliothèque « Pages » d’un site SharePoint. 

Prenons le type « Projet » défini précédemment. Celui-ci est caractérisé pour le moment comme étant une information « formelle » et non un document:

Affichage d'un élément avec le modèle liste

Si je voulais visualiser les métadonnées d’un projet sous SharePoint, voici ce que cela donnerait avec le mécanisme d’affichage classique de liste (la version de SharePoint importe peu):

Visualisation avec le formulaire de liste

Imaginons maintenant que je souhaite afficher un peu plus de « style » pour un projet. Les informations de base sont conservées mais le type de contenu parent change pour devenir une page publication ce qui donne le modèle relationnel suivant:

Affichage d'un élément avec le modèle de publication

Voici un aperçu de l’affichage (après création d’un gabarit adapté. Voir  Créer des gabarits de page rapidement avec SharePoint 2013):

Visualisation avec un gabarit de page de publication.

Limitations du modèle de publication classique SharePoint

Vous avez probablement remarqué un problème inhérent à l’utilisation de pages de publication:

 Vous êtes obligatoirement lié à un type de contenu SharePoint parent de type « Page » et non plus un « Élément » ce qui implique que vos métadonnées « métiers » sont mélangées avec les métadonnées propres à une page (Date de publication, Contact, Audience cible, …).

 Le choix de l’emplacement de stockage vous est imposé (bibliothèque de pages du site SharePoint de publication). Cela implique généralement l’obligation de gérer la sécurité au niveau des éléments ou dossiers de la bibliothèque eux-mêmes, si besoin est (ce qui n’est pas une bonne pratique).

Note : Il est possible de créer des pages dans d’autres bibliothèques que celle « Pages », mais il s’agit clairement d’un bug. Pour plus d’informations vous pouvez lire l’annexe Créer des pages en dehors de la bibliothèque de pages dans SharePoint : attention au bug!

Comme vous le voyez, ces contraintes peuvent nuire à la cohérence de votre modèle de données si vous ne l’anticipez pas dès le départ.

Cependant dans SharePoint 2013, il existe une alternative au modèle de publication classique, à savoir, la publication intersites (ou « Cross-site Publishing » en anglais ou son acronyme « XSP »). Mais que signifie ce terme? Il s’agit d’un concept très simple permettant de séparer la définition de la donnée de sa présentation, en se basant sur les mécanismes de recherche. Voici une schématisation du concept que l’on peut retrouver sur le site de Microsoft :

Principe de la publication intersites

  1. «…Le contenu est créé dans des bibliothèques et des listes qui sont partagées comme catalogues dans la collection de sites de création.
  2.  Le système de recherche analyse le contenu et crée l’index de recherche.
  3.  Un utilisateur visualise une page sur un site de publication, ce qui déclenche des requêtes de la part des composants WebPart de recherche.
  4.  Les résultats sont renvoyés à partir de l’index de recherche et affichés dans les composants WebPart de recherche sur la page…»

Comme vous le voyez, ce principe permet de visualiser, à la même manière d’une page de publication classique,  de l’information typée sous forme de gabarit, à la différence près que cette information provient d’une source de données différente (potentiellement d’une autre collection  de sites, d’où le nom de la fonctionnalité).

En d’autres termes, on sépare ici les données de la présentation en s’appuyant sur les mécanismes de recherche.

Quelques avantages de ce modèle:

  • Cette dissociation permet de conserver  un  modèle de données adapté aux contraintes (sécurité des éléments, stockage dans les listes et bibliothèques, etc.).
  • On bénéficie des mécanismes de publication classiques pour la visualisation d’information. Cela implique que les pages seront tout de même stockées dans la bibliothèque de pages du site.
  • Il est possible de combiner ce modèle à une navigation gérée par taxonomie (ceci n’est cependant pas l’objet de ce guide).

En revanche, le principal inconvénient de ce système réside dans la technologie utilisée : la recherche.  En effet, les données affichées ne représentent que la réalité de l’index et non celle de SharePoint. Cette technique est donc à considérer selon votre besoin. Voir  le chapitre Préambule – L’accès à l’information : le nerf de la guerre pour plus de détails.

Néanmoins, ce concept n’est pas si révolutionnaire que ça, il a simplement été régi dans un cadre d’utilisation dans SharePoint, il est aussi possible de l’appliquer aux versions antérieures à 2013, avec certes plus de gymnastique.

En effet, des gabarits de pages classiques, couplées à des composants WebPart de résultats de recherche ou même de requête de contenu (ne requêtant que sur un seul champ d’un type particulier) peuvent conserver cette fameuse séparation. Dans le cas de composants WebPart de requête de contenu, on s’affranchi même des contraintes de réalité « différée » induite par les mécanismes de recherche.

Pages « opérationnelles » et « informatives »

Revenons à l’exemple de tout à l’heure. Pour la gestion des projets, je désire à la fois afficher une sorte de « Fiche projet » autre qu’un formulaire de liste classique avec un style graphique attrayant, mais sans pour autant modifier mon modèle de données et mélanger mes métadonnées avec celles d’une page de publication. De plus, je veux pouvoir mettre en relation mes instances de projets avec des documents et des personnes qui leur sont liées, et ceci dans une interface distincte.

Prenons le modèle de base:

Type de contenu d'élément

Et ajoutons la partie pour la gestion des fiches:

Type de contenu de document

Ce qui nous donne le principe d’affichage suivant:

Principe des pages opérationnelles et informatives

Le type « Fiche de projet » permet de visualiser un projet unique et ses métadonnées avec un style particulier. C’est une page Informative.

Un type « Projet » est la source de cette page et peut être utilisée dans d’autres pages, agrégé avec d’autres données (documents, personnes). Ce sont des pages opérationnelles.

Comme vous le voyez, je peux avoir plusieurs pages répondant à des besoins différents, mais basées sur la même information.

 Note : Il est possible d’appliquer ce principe pour des composants se basant sur le langage de requête structuré en utilisant la propriété « Page Field Value » du CQWP et les pages de publication.

Comparaison d’utilisation

Pour résumer, voici les différents types de pages ainsi que le cas d’utilisation dans une application:

Type de pages Description
Page Wiki  Édition rapide de texte statique en mode WYSIWYG
 Pas de connexions possibles entre les données
 Uniquement dans la bibliothèque « Sites Pages »
Page de composants WebParts  Cadre modulaire configurable
 Mise en relation simple d’informations via des connexions de WebPart
 Peut être stockée dans n’importe quelle bibliothèque de documents.
Page de publication  Contrôle de l’information (cycle de publication et style)
 Liée à des gabarits de pages
 Peu intégrer des WebPart (si utilisation de la publication intersites)

Ainsi que les pages selon les utilisations:

Utilisations
Affichage de données statiques Agrégation de données Affichage de données typées
Pages Wiki Pages de composants WebParts Pages de publication
Formulaire de liste ou bibliothèque
Exemples
Un texte de bienvenue Un tableau de bord de gestion de projets Une fiche descriptive de projet
Dans le cadre de l’histoire utilisateur que je suis en train de traiter, j’ai besoin de mettre en relation des informations typées. Mon choix se portera logiquement sur une page de composant WebPart.

+ There are no comments

Add yours