Partie 12: Définir les comportements relationnels

Partie 12: Définir les comportements relationnels


Aperçu de l’article

Notions clés

Les comportements relationnels correspondent aux fonctionnements dynamiques que l’on peut observer dans les pages présentant les informations. C’est un élément essentiel de toute interface destinée à l’utilisateur et il existe plusieurs moyens d’y répondre dans SharePoint.
Connexion de Web Parts Connexion par identifiants de requête de recherche
 
Quelles sont les contraintes relationnelles portant sur ces informations?
Une fois les requêtes identifiées pour la récupération des informations, nous nous intéressons aux contraintes relationnelles entre les types présents. Précédemment, nous avons défini des relations entre les types. Il s’agit maintenant de voir comment elles se matérialisent dans la page concernées et de gérer les différentes contraintes qui peuvent s’imposer. On s’intéresse ici aux notions de filtrages et connexions en réponse à des actions. Les événements pouvant survenir sont les suivants :

  • Directs : Action de l’utilisateur sur un ou plusieurs éléments. Ex : L’utilisateur sélectionne un élément dans une liste
  • Indirects: Changement d’état d’un autre élément sur la page. Ex : L’état d’un composant a changé sur la page.
Soit le besoin « Rechercher un projet », avec l’interface définie précédemment. Les comportements identifiés sont les suivants: Identification visuelle des comportements pour "Rechercher un projet"

Description Type Déclenchement
Les projets affichés dans la liste de projet doivent contenir les mots clés présents dans la zone de recherche dans leur nom. Direct Lorsque l’utilisateur appuie sur « Entrer » dans la boîte de recherche.
Les documents de projets et les personnes doivent correspondre au projet sélectionné dans la liste de projets. Direct Lorsque l’utilisateur sélectionne un projet dans la liste.

Mécanismes de connexion et filtrage dans SharePoint

La mise en relation et le filtrage des données sont des choses que l’on rencontre systématiquement dans les requis des interfaces utilisateur. En effet, ces notions sont essentielles aux interfaces de type gestion. Dans SharePoint, quand il est question de mise en relation de données contextuelles, cela signifie qu’au sein d’une même page de navigation, certains des composants vont agir en tant que filtres, et d’autres en tant que récepteurs de ces filtres. Selon le moyen d’accès à l’information que vous choisissez, vous ne disposez pas des mêmes possibilités et mécanismes pour la connexion et le filtrage de données.

Composants basés sur le langage de requête structurée

Si vous vous rappelez l’explication faite dans le chapitre précédent, cette méthode est particulièrement adaptée au filtrage et donc à la mise en relation de données dans un contexte car elle ne nécessite pas de connaître le nom des champs à l’avance. Les solutions proposées ici sont les mêmes pour SharePoint 2007, 2010 ou 2013.

SharePoint 2010 et 2013 : La connexion de WebPart

Par l’entremise d’une interface graphique, SharePoint propose peu de façons pour connecter des données métiers relationnelles. En fait, il n’y a qu’un seul moyen : la connexion de WebPart de liste. La connexion de WebParts de liste En effet, rappelez-vous de ce composant :

Toutefois, tel qu’énoncé précédemment, ce WebPart impose des contraintes architecturales et n’est pas adapté à toutes les situations. Lorsque vous réalisez une connexion entre WebPart, vous faites une correspondance EXACTE sur une ou plusieurs colonnes. Il est en effet impossible nativement de faire une correspondance relative de type « Contient ».

Les composants de filtres

Depuis SharePoint 2007 et dans la version « Entreprise » du produit, il existe une pléthore de WebPart annexes pouvant être connectés à celui de liste permettant de lui appliquer des filtres de natures différentes. Un composant WebPart de filtre est, comme son nom l’indique, un composant permettant d’appliquer des filtres sur un WebPart de liste (pas possible sur un autre filtre) au sein d’une même page à travers le mécanisme de connexion entre composants. Les composants WebPart de filtre   À noter que le WebPart de liste est lui-même un composant de filtre. Voici la liste des composants de filtres disponibles pour toutes les éditions de SharePoint, de 2007 à 2013. Rappel : Il est obligatoire de disposer de la version Entreprise de SharePoint (à l’exception du composant WebPart de liste qui est disponible dans toutes les versions).

  • Filtres libres
    • Texte libre
    • Paramètre de requête dans l’URL
    • Date
  • Filtres provenant de sources de données existantes
    • Liste de choix
    • Catalogue de données métier
    • Liste SharePoint
    • WebPart de liste
  • Filtres automatiques de page
    • Champ de la page
    • Utilisateur connecté

Pour ceux qui ne disposent pas de la version Entreprise de SharePoint, il est tout de même possible de définir des filtres textuels connectés aux autres WebPart grâce au composant de formulaire WebPart HTML. Celui-ci permet de créer, moyennant du code JavaScript, des filtres connectables aux autres composants. (Le composant de filtre du pauvre…) Le composant WebPart de filtre du pauvre  

HTML Form WebPart

Composants basés sur le langage de recherche

Que ce soit en SharePoint 2010 ou 2013, il vous est également possible de connecter plusieurs composants utilisant le langage de recherche au sein d’une même page. Cependant, là encore, les mécanismes et les possibilités diffèrent.

SharePoint 2010 : La connexion par identifiant de requête

Les mécanismes de connexion des composants de recherche sur SharePoint 2010 fonctionnent par un système d’identifiant de requête. Cependant, il ne concerne pas tous les composants. Voici les principaux composants impliqués par ce mécanisme :

  • WebPart de résultats de recherche
  • Panneau de raffinement
  •  Boite de recherche

Un identifiant de requête permet de « partager » une requête de recherche entre des composants sur la même page. Pour illustrer ce concept, prenons l’exemple suivant: Principe de la connexion par identifiant de requête en SharePoint 2010 Identifiants de requête personnalisés Deux composants WebParts de résultats de recherche sont connectés par l’identifiant de requête #2. Le premier composant possède une requête fixe avec le mot clé « Projet » et le second possède un ajout à la requête principale avec le mot clé « Commercial ». Par ce principe, les mots clés sont concaténés dans le deuxième composant. Note : Il semblerait que le WebPart maître (possédant la requête initiale) soit le dernier ajouté sur la page avec cet identifiant de requête. Il est possible de définir jusqu’à 4 identifiants personnalisés sur une même page. De même, ces identifiants fonctionnent surtout sur les options du composant de résultats de recherche « Requête de mot-clé fixe » et « Ajouter du texte à la requête »: Identifiant personnalisé de requête Identifiant de requête utilisateur Trois composants WebParts sont reliés par l’identifiant de requête correspondant à la requête de l’utilisateur. Cette requête est fournie par le composant de boîte de recherche. Notez qu’il n’est pas possible de définir un identifiant pour ce composant, car celui-ci est toujours « Requête de l’utilisateur ». Cela m’amène à parler de cet identifiant un peu particulier car, en réalité il s’agit tout simplement de la requête passée dans l’url de la page de recherche cible. Paramètre "Keyword" Quand vous définissez l’identifiant de requête « Requête utilisateur », vous dites simplement  aux composants d’afficher les résultats en fonction de la valeur du paramètre « k » dans l’url et rien de plus.

SharePoint 2013 : La connexion par fournisseur de résultats

La connexion entre composants de recherche en 2013 a été améliorée par rapport à la version 2010. Ici, exit les identifiants de requête! Il est maintenant possible de définir explicitement une relation entre les composants. Voici les composants de recherche permettant d’être connectés: Panneau de raffinement Connexion directe du panneau de raffinement en SharePoint 2013 Boîte de recherche Connexion directe de la boîte de recherche en SharePoint 2013 À noter que maintenant, les mots clés issus de la boîte de recherche (et donc de l’URL) peuvent être récupérés directement à partir d’une variable {SearchBoxQuery}. Recherche de contenu Connexion directe des WebParts de recherche de contenu  Note : Bien qu’étant possible, ce cas me paraît un peu douteux dans la réalité. À part permettre de changer le gabarit d’affichage, les champs associés, la position d’affichage de résultats ainsi que la pertinence des résultats, il ne vous permettra pas, à la manière de SharePoint, de répartir des termes de la requête globale entre les composants d’une même page (le bouton de l’assistant de requête étant bloqué une fois le fournisseur choisi ?!). Filtres dynamiques Avec SharePoint 2013, plusieurs nouveaux filtres apparaissent également utilisables directement dans votre requête par le biais de l’assistant de construction de requêtes de recherche présente dans les WebParts « recherche de contenu » et  « résultats de recherche ». Il est maintenant possible de filtrer sur:

  • Requête de la boîte de recherche
  • Utilisateur exécutant la requête
  • Valeur de paramètre de l’URL
  • Valeur de « Token » dans l’URL
  • Valeur d’un champ sur la page
Filtres dynamiques en SharePoint 2013
Pour la liste des filtres sous SharePoint 2013 : http://technet.microsoft.com/en-us/library/jj683123 Si vous avez été attentifs, ces filtres ne sont pas là par hasard et sont très similaires à ce que proposaient déjà les filtres adaptés au langage CAML. Cependant, les possibilités ont été élargies pour construire des requêtes dynamiques plus facilement à même les composants de recherche.

Les composants de filtres

De la même façon que le langage de requête structurée, il existe des composants agissants en tant que filtres pour d’autres composants. Le panneau de raffinement Le composant WebPart panneau de raffinement est un composant majeur apparu avec SharePoint 2010 et repris avec 2013 (pas d’équivalent en 2007), permettant de naviguer par les propriétés de l’information. Le panneau de raffinement de SharePoint Cet outil dispose de plusieurs options intéressantes comme la possibilité d’ajouter ses propres filtres. Son point faible majeur concerne le multilinguisme et la précision des raffinements. Les filtres extraits du contenu trouvé sont en réalité basés sur un sous-ensemble de ce contenu. Ce sous-ensemble est caractérisé par un nombre de résultats sous la forme du paramètre « Précision de l’index » dans le composant de résultats de recherche auquel il est lié. Au maximum, il ne peut considérer que 500 résultats pour extraire ses filtres. Si vous avez déjà rencontré une incohérence sur le compteur d’éléments, cela provient sans doute de ce comportement. Un point à noter également, pour beaucoup de gens, le panneau de raffinement propose des filtres cumulables lors d’une seule recherche, or ceci EST FAUX ! Il n’est pas rare de voir des clients demander des cases à cocher pour chacun des filtres mais cela va à l’encontre du fonctionnement du composant. On oppose une stratégie de filtres fixes (on connait les filtres et on les restreint selon le contenu affiché) vs une stratégie de filtres dynamiques (on ne connaît pas les filtres à l’avance et la restriction se fait selon ceux extraits du contenu) qui dans le cas du panneau de raffinement est conçue pour que jamais vous ne puissiez obtenir un résultat vide. En effet, au final, c’est le contenu qui pilote les filtres et non le contraire. Si vous souhaitez utiliser ce composant dans un site multilingue, je vous conseille cette série d’articles :

La boîte de recherche Ce composant permet de capturer une requête de recherche d’un utilisateur au format KQL. Cependant, celui-ci agit indirectement en tant que filtre. En effet, il manipule simplement l’URL la page de recherche en positionnant la valeur du paramètre correspondant aux mots clés tapés (« k ») et éventuellement le périmètre de recherche associé (« cs »). Il correspond également à l’identifiant de requête « Requête utilisateur ». Boîte de recherche   Le WebPart de résultats de recherche En SharePoint 2010, ce composant peut également agir comme filtre pour d’autres composants par l’intermédiaire de la connexion par identifiant de requête. Le WebPart de recherche de contenu En SharePoint 2013, il peut également être connecté à l’un de ses pairs bien que l’utilité réelle reste encore à démontrer.

Scénarios hybrides

Connaissant les différentes possibilités de connexions et de filtrage pour chacun des moyens d’accès à l’information, il est possible de combiner les scénarios. Ces derniers sont les mêmes pour SharePoint 2010 et 2013. Le point commun entre les composants basés sur CAML et ceux basée sur KQL est l’URL. Ainsi, il est possible de combiner des composants d’univers différents par ce moyen:  Avec un WebPart de requête de contenu et une boîte de recherche Scenario1   La connexion se fait grâce à la propriété [PageQueryString]. Attention, celle-ci est sensible au formatage (« Montréal » = « Montr%C3%A9al »).  Ce scénario peut être intéressant pour faire de la recherche instantanée par mot clés (non basée sur l’index de recherche), à l’intérieur même d’une colonne SharePoint.   Avec un WebPart de liste, un WebPart de filtre URL, et une boîte de recherche Si vous vous souvenez du mécanisme de connexions entre WebParts, il n’est possible ici que de faire une correspondance EXACTE sur une colonne. Connexion entre un WebPart de liste, un WebPart de filtre URL, et une boîte de recherche    Ce scénario, bien que possible, n’est pas forcément pertinent car vous pourriez obtenir le même résultat avec un WebPart de filtre de type « Texte libre ». En revanche, il prend tout son sens si vous faites cohabiter sur la même page des composants uniquement  basés sur la recherche et que vous souhaitez n’avoir qu’un point d’entrée pour les requêtes des utilisateurs.

Tableau récapitulatif des connexions entre composants

Voici un tableau récapitulatif des différentes connexions possibles entre les composants WebPart SharePoint, toutes méthodes d’accès à l’information confondues. Connexions possibles entre les composants SharePoint Note: En référence à la section sur les flux de lecture et écriture, vous remarquerez que les composants de la ligne « récepteurs » sont tous issus des composants gérant au moins le flux de lecture.


+ There are no comments

Add yours