Archives de catégorie : Sites collaboratif

Personnaliser vos sites SharePoint 2013 avec le Client Side Rendering (CSR) et le JS Link

Introduction

Effectuer des personnalisations dans l’interface utilisateur de SharePoint a toujours été un défi pour bien des développeurs. Dans les versions 2007 et 2010, on utilisait majoritairement le XSLT pour faire des personnalisations bien que c’était relativement complexe à s’y familiariser. D’autres utilisaient des WebParts de type Éditeur de contenu pour effectuer des modifications JavaScript directement dans une page et dans ce cas la difficulté est de trouver une « poignée » pour appliquer les modifications sur un élément précis. La fonctionnalité JSLink est arrivé dans SharePoint 2013 pour simplifier la vie aux développeurs en leur permettant de faire des personnalisations avec des langages qu’ils connaissent déjà : HTML, JavaScript et CSS. Grâce à cette fonctionnalité, on peut contrôler via un fichier JavaScript le rendu visuelle des éléments suivant :

  • Champ
  • Élément
  • Formulaire de liste
  • Vue
  • WebPart

XSL/XSLT vs Client Side Rendering

Le tableau ici-bas résume bien les différences entre les deux fonctionnalités :

XSL/XSLT Client Side Rendering
Performance
  • Plus rapide lorsqu’il y a un grand nombre d’éléments à afficher.
  • Aucune charge additionnel dans le navigateur.
  • Plus lent lorsqu’il y a un grand nombre d’éléments à afficher.
  • La vitesse du navigateur client peut avoir un impact sur la performance.
  • Réduit la charge du serveur.
Complexité
  • Langage complexe à apprendre initialement.
  • Difficile à déboguer (Souvent par essaie-erreur).
  • Temps de développement plus grand.
  • Facile de déboguer du JavaScript, HTML et CSS avec les navigateurs modernes.
  • Temps de développement réduit.
Flexibilité
  • Limité aux fonctions XSLT 1.0 pour SharePoint 2010 et 2013.
  • Limité pour faire un rendu visuel complexe.
  • Très efficace pour faire des opérations coûteuse (ex : Count dans une vue).
  • Permet de cibler les personnalisations sur une vue, un champ, une WebPart, etc…
  • Possibilité d’utiliser des plugins (ex : JQuery).
  • Très adapté pour faire un rendu visuel complexe.
  • Inefficace pour faire des opérations coûteuses (ex : Count dans une vue).
Compatibilité
  • Indépendant du navigateur.
  • Supporté dans SP2010 et SP2013.
  • Fonctionne même si le JavaScript est désactivé dans le navigateur.
  • Génère du contenu statique qui est bien interprété par les robots d’indexation.
  • Adapté pour des sites publiques.
  • Dépendant du navigateur.
  • Supporté dans SP2010 et SP2013
  • Requiert que le JavaScript soir activé dans le navigateur.
  • Génère du contenu dynamique qui n’est pas bien interprété par les robots d’indexation.
  • Non-adapté pour des sites publiques.

Comment configurer le JSLink?

Pour référencer vos fichiers dans la propriété JSLink vous pouvez spécifier un jeton de remplacement (Token) ainsi qu’un séparateur (|) si vous avez plusieurs fichiers.

Les jetons disponibles sont les suivants :

  • ~site : correspond au URL du site Web courant.
  • ~sitecollection : correspond au URL de la collection de site parent du site Web courant.
  • ~layouts : correspond au dossier « _layouts/15 » de la web application.
  • ~sitelayouts – correspond au dossier layouts du site courant (ex : site/monsite/monsoussite/_layouts/15).
  • ~sitecollectionlayouts : correspond au dossier layouts de la collection de site courante (Ex:  /sites/monsite/_layouts/15).
  • ~sitelayouts – correspond au dossier layouts du site courant (Ex: /site/monsite/monsoussite/_layouts/15).

En utilisant ces jetons avec le séparateur on peut donc référencer plusieurs fichiers de scripts dans le JSLink.

Ex : ~site/style library/­monScript1.js|~sitecollection/style library/monScript2.js.

On peut spécifier la propriété JSLink en utilisant ces méthodes :

  • PowerShell
  • Code serveur C#/VB en utilisant l’API
  • Code serveur déclaratif XML
  • Interface utilisateur

Pour simplifier ce billet, je vous propose la méthode utilisant l’interface utilisateur :

jslink_link

Pour plus de détail sur les autres méthodes permettant de spécifier la propriété JSLink, je vous recommande le billet de Tobias Zimmergren.

Fonctionnement technique

À l’intérieur de ces fichiers, le JavaScript est utilisé pour « overrider » :

  • la manière dont les données sont affichés
  • le contenu à afficher

Voici un exemple de code permettant de modifier la valeur d’un champ dans une vue :

// Créer un namespace pour la fonction afin d'éviter des collisions avec les autres fonctions
var sharepointerie = sharepointerie || {};

(sharepointerie.CustomizeFieldRendering = function () {

// Initialise les variables pour overrider les objets
 var overrideCtx = {};
 overrideCtx.Templates = {};

 /*
 * Force la valeur "SharePointerie" dans le titre de tous les éléments.
 */
 overrideCtx.Templates.Fields = {
 'LinkTitle': { 'View' : 'SharePointerie' }
 };

 /*
 * Enregistre l'override du template.
 */
 SPClientTemplates.TemplateManager.RegisterTemplateOverrides(overrideCtx);
})();

Techniquement, on construit un objet qui sera ensuite utilisé afin d’enregistrer l’override du template. L’objet « overrideCtx » peut ensuite interagir avec ces propriétés :

  • View
  • Header
  • Body
  • Footer
  • Group
  • Item
  • Fields
  • OnPreRender
  • OnPostRender

Dans l’exemple on utilise la propriété Fields avec ce format :

overrideCtx.Templates.Fields = {NomDuChamp: {Porté : Override}}

  • NomDuChamp : Le nom interne du champ que l’on veut overrider.
  • Porté : Les choix possibles « View », »DisplayForm », »EditForm », et « NewForm » permettent de spécifier l’endroit ou l’on veut faire l’override.
  • Override : Contient une chaîne HTML ou une fonction à exécuter à l’intérieur de tags « <#= #> ».

Résultat (avant l’ajout du CSR) :

jslink_technique_avant

Résultat (après l’ajout du CSR) :

jslink_technique_apres

Des exemples concrets

1) Limiter la taille du texte dans le champ « Corps » d’une liste d’annonces

Cet exemple de code, réalisé par Muawiyah Shannak, permet d’afficher un résumé du corps d’une annonce et d’afficher la version intégrale dans une infobulle.

Pour déployer la solution :

  1. Télécharger le fichier CSR.
  2. Ajouter le fichier sous /Style Library/.
  3. Créer une liste de type Annonces
  4. Créer ou modifier une vue afin d’afficher le champ Corps.
  5. Modifier la page contenant la List View WebPart.
  6. Aller dans les propriétés de la WebPart et ajouter le fichier JSLink (~sitecollection/Style%20Library/SubstringLongText.js) dans la propriété Lien Js (JSLink) sous l’onglet Divers
  7. Cliquer sur Appliquer et quitter l’édition de la page.

Résultat (avant l’ajout du CSR) :

jslink_limite_texte_avant

Résultat (après l’ajout du CSR) :

jslink_limite_texte_apres

2) Ajouter des onglets dans un formulaire

Cet exemple de code, réalisé par Muawiyah Shannak, permet d’utiliser JQuery Tabs pour afficher des onglets dans un formulaire.

Pour déployer la solution :

  1. Télécharger le fichier CSR.
  2. Ajouter le fichier sous /Style Library/.
  3. Créer une liste personnalisé
  4. Ajouter des colonnes à la liste
  5. Modifier l’objet tabsObj selon vos besoin.
  6. Créer une nouvelle vue contenant le champ Lien
  7. Modifier les pages « newform » et « editform » de la liste
  8. Aller dans les propriétés de la WebPart et ajouter le fichier JSLink (~sitecollection/Style%20Library/Tabs.js) dans la propriété Lien Js (JSLink) sous l’onglet Divers
  9. Cliquer sur Appliquer et quitter l’édition de la page.

Résultat (avant l’ajout du CSR) :

jslink_tabs_avant

Résultat (après l’ajout du CSR) :

jslink_tabs_apres

Points à faire attention

  • Il peut y avoir des conflits avec le CSR si vous utilisez la fonctionnalité « Minimal download strategy ». Pour corriger ce problème consulter ce billet.
  • Le code de vos fonctions CSR ne devrait pas être défini dans le Namespace globale.
  • Le nom interne des colonnes est utilisé dans le code JavaScript des fonctions CSR alors favoriser des noms de colonnes sans espaces et sans caractères accentués.
  • Le CSR, contrairement au XSLT, dépend du navigateur alors assurez-vous de tester dans plusieurs navigateurs.

Conclusion

Pour conclure, le CSR comporte plusieurs avantages au niveau de la flexibilité et de la complexité comparativement au XSLT. Cependant, il vient aussi avec certaines lacunes en lien avec la performance et la compatibilité. Il y a donc énormément de potentiel à utiliser le CSR pour vos personnalisations (Validations, AJAX, etc…) mais comme il y a des limitations, je crois que le XSLT va continuer d’exister en parallèle. Je vous invite donc à l’essayer et à me donner vos commentaires!

Références

Voici quelques liens pour approfondir vos connaissance sur le CSR / JSLink.

Exemples de codes CSR réalisé par Muawiyah Shannak

Perfomance de l’utilisation du CSR via le JSLink

5 faits concernant l’utilisation du JSLink

Comment : personnaliser un type de champ à l’aide de rendu côté client

Comment : personnaliser le mode Liste dans les apps pour SharePoint à l’aide du rendu côté client

Introduction au CSR par Ross Bradbrook

Bon point de départ sur l’utilisation de l’API CSR

Conversion de solutions de ferme SharePoint 2010 vers SharePoint 2013

De retour sur mon blog après des vacances bien mérité. On m’attendait de pied ferme pour évaluer avec d’autres collaborateurs la conversion de plusieurs solutions de ferme SharePoint 2010 vers SharePoint 2013. Je vais donc tenter, dans ce billet, de vous aider à identifier et à corriger plus rapidement d’éventuelles problématiques de conversion.

Conversion des Requête de contenu (Content Query WebPart) SharePoint 2010 vers SharePoint 2013

Dans les composantes contenant des Requêtes de contenu (Content Query WebPart), nous sommes tombés sur une SharePointerie lors de la conversion. À première vue, après avoir effectué la conversion vers SharePoint 2013 de cette composante avec Visual Studio 2013, le code compile!

conversion_sp2013_Upgrade

On est prêt pour aller en PROD ? Pas tout à fait! J’ai alors déployé la composante et lorsque j’ai essayé de la tester alors j’ai obtenu un message d’erreur lors de l’affichage de la WebPart.

Dans la plupart des Requête de contenu à convertir vers 2013, l’aspect visuel a été modifié afin de fournir une expérience utilisateur plus riche. Pour s’y prendre, le lien vers les fichiers XSL par défaut a été modifié dans le XML du fichier *.webpart.

Exemple d’un fichier *.webpart SharePoint 2010

<webParts>
<webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
 <metaData>
   ...
 </metaData>
 <data>
 <properties>
   <...>
   <property name="MainXslLink" type="string">/Style Library/XSL Style Sheets/POC.SHP.WebPart.Main.xsl</property>
   <property name="ItemXslLink" type="string">/Style Library/XSL Style Sheets/POC.SHP.WebPart.Item.xsl</property>
   <...>
 </properties>
 </data>
 </webPart>
</webParts>

J’ai alors tenté de retirer les liens XSL afin d’utiliser l’affichage par défaut de la Requête de contenu (Content Query WebPart) et le tout s’est affiché mais sans inclure l’aspect visuel personnalisé. On s’est donc dit que le URL vers le fichier XSL n’était pas bon. Je me suis alors rappelé que dans SharePoint 2013, il faut maintenant spécifier dans le URL le dossier /15/ (Aussi appelé Hive) avant le /Style Library/.

Exemple d’un fichier *.webpart corrigé pour SharePoint 2013

<webParts>
<webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
 <metaData>
   ...
 </metaData>
 <data>
 <properties>
   <...>
   <property name="MainXslLink" type="string">/15/Style Library/XSL Style Sheets/POC.SHP.WebPart.Main.xsl</property>
   <property name="ItemXslLink" type="string">/15/Style Library/XSL Style Sheets/POC.SHP.WebPart.Item.xsl</property>
   <...>
 </properties>
 </data>
 </webPart>
</webParts>

Pourquoi est-ce ainsi?

Dans SharePoint 2013, il est possible d’installer à la fois des solutions SharePoint 2010 et 2013. Ceci est supporté par le fait qu’il y a deux dossiers virtuel, un pour le SP2010 (14) et l’autre pour les SP2013 (15).

Si votre code SharePoint 2010 contient des références vers /_layouts/ ou /Style Library/, il vous faudra les mettre à jour respectivement pour /_layouts/15/ ou  /15/Style Library/ afin que le chemin soit résolus correctement lors de l’utilisation de la solution dans SharePoint 2013.

Le tableau ici-bas présente les différences des chemins :

SharePoint 2010 SharePoint 2013
/Style Library/scripts/jquery.min.js /15/Style Library/scripts/jquery.min.js
/_layouts/images/test.jpg /_layouts/15/images/test.jpg

Conversion des Visual WebParts SharePoint 2010

Lors de la conversion des composantes de ferme de type Visual Web Part nous sommes tombé sur une autre SharePointerie. Cependant, lorsqu’on connait la recette vue précédemment ça devient un peu plus évident.

Lorsque j’ai ajouté la Visual WebPart dans ma page, ça à tout simplement fait exploser la page et SharePoint m’a proposé la page de maintenance afin de supprimer la WebPart en erreur. C’est très gentil de sa part, mais ce n’est pas très utile pour diagnostiquer un problème. Alors, j’ai décidé de m’attacher au code et de déboguer la méthode CreateChildControls qui est lancé au tout début lors de l’affichage de la Visual WebPart.

C’est alors que j’ai eu ce message d’exception : The file ‘/_controltempates/…/…UserControl.ascx’ does not exist.

conversion_sp2013_debug_visualwebpart

Pourtant mon fichier *.ascx est bien déployé dans le dossier :

conversion_sp2013_15_visualwebpart

J’ai alors appliqué la même recette que vue précédemment en ajoutant le /15/ dans le URL tout de suite après le /_controltemplates/ et bien sûr ça a bien fonctionné :

conversion_sp2013_debug_passed_visualwebpart

Il faut comprendre que le commentaire dans le haut de la constante _ascxPath indique : Visual studio might automatically update this path when you change the Visual WebPart.

Cependant, Visual Studio ne l’a pas fait lors de la conversion de SharePoint 2010 vers SharePoint 2013 ! J’ai ouvert un billet sur le site de Visual Studio User Voice alors n’hésiter pas à aller voter pour celui-ci. Qui sais, un jour Visual Studio sera peut-être amélioré et cette SharePointerie n’existera plus!

Conclusion

En conclusion, si votre code SharePoint 2010 contient des références vers /_layouts/, /_controltemplates/ ou /Style Library/ vous aurez à modifier vos URL pour que ça fonctionne dans SharePoint 2013. Il ne s’agit pas d’une liste exhaustive des problématiques de conversion que l’on peut retrouver mais c’est un bon point de départ. De plus, lorsque l’on connait la recette pour corriger les problèmes c’est beaucoup plus simple et on perd beaucoup moins de temps.

Avez-vous effectué des conversions SharePoint 2010 vers SharePoint 2013 ? Est-ce que vous avez rencontré des SharePointeries? N’hésitez pas à commenter pour lancer la discussion!

Comment créer un service Web WCF (REST) personnalisé dans SharePoint 2013

Récemment, un collègue m’a demandé comment faire pour exécuter du code serveur dans un bouton du ruban. Je lui avait alors répondu : Le plus simple c’est de te faire une page aspx avec une WebPart contenant du code serveur. C’est comme si tu appelais un service web mais au lieu de cela c’est une page aspx avec des paramètres dans le querystring.

Ex : Lors du clique sur un bouton du ruban on appel une page avec des paramètres pour effectuer la modification d’un élément. Assumons que la page se nomme ModifierElement.aspx, alors il sera possible d’y accéder seulement à partir de sont chemin fixe : http://serveur/sites/site/web/pages/ModifierElement.aspx?Id=1

Dans le code du ruban (CustomAction), on peut seulement utiliser du code JavaScript (CSOM) et pour utiliser du code serveur on doit invoquer un événement via le bouton. Ces deux dernières méthodes comportent un certain niveau de complexité ainsi que des limitations.

L’approche de la page aspx est souvent utilisé pour sauver du temps lors du développement. Cependant, après quelques recherches je suis tombé sur une meilleure façon d’exécuter du code serveur en utilisant un Service Web WCF (REST) personnalisé hébergé dans SharePoint.

Comment faire un service Web (WCF) personnalisé ?

Les services Web natif de SharePoint peuvent être accédés à partir du chemin _vti_bin.  Lorsque l’on va développer notre service Web personnalisé il sera accessible via ce même chemin.

Ex : Assumons que le service Web personnalisé se nomme Service.svc alors il sera possible d’y accéder, entre autres, à partir des chemins suivants :

* C’est un avantage comparativement à la méthode de la page contenant une WebPart 

Étape 1 – Créer un projet Visual Studio 2012

  • Créer un nouveau projet à partir du modèle « SharePoint 2013 – Empty Project »
  • Nommer le projet « POC.SharePoint.WebServiceHelloWord »
  • Sélectionner « Deploy as a farm solution »

Étape 2 – Ajouter les références

  • Ajouter les références suivantes dans votre projet : Microsoft.SharePoint.Client.ServerRuntime 15.0.0.0 et System.ServiceModel 4.0.0.0

referenceWcf

Étape 3 – Ajouter un SharePoint Mapped Folder (ISAPI)

Le dossier ISAPI est le dossier spécial dans la « hive » SharePoint où tous les services WCF doivent être déployés. Ce dossier est associé au chemin « _vti_bin » dans IIS et ainsi les services déployés dans ce dossier peuvent être accédé par ce URL : http://serveur/_vti_bin/{NomService}.svc

Pour ajouter un nouveau Mapped Folder on sélectionne le projet et ensuitie on clique de droit -> ajouter -> SharePoint Mapped Folder :

mappedFolderWcf

Ensuite sélectionner le dossier ISAPI :

isapiWcf

C’est une bonne pratique de se créer un sous dossier spécifique à votre projet e.g.: « WebServiceHelloWord » .

Étape 4 – Définir le Service, le Contract et l’Interface

Dans le Mapped Folder « ISAPI » ajouter les fichiers suivants :

  • un fichier texte nommé « Service.svc » (Fichier du service lui même qui sera déployé dans le hive de SharePoint et qui sera appelé dans IIS)
  • un fichier Interface nommé « IService.cs » (Fichier contenant le contrat d’opération du service)
  • un fichier Classe nommé « Service.svc.cs » (Fichier contenant l’implémentation de l’interface du service)

Étape 5 – Définir le contenu du Service, du Contract et de l’Interface

Ouvrez le fichier Service.svc.cs et y insérer le code suivant :

using Microsoft.SharePoint.Client.Services;
using System.ServiceModel.Activation;

namespace POC.SharePoint.WebServiceHelloWord.ISAPI.WebServiceHelloWord
{
 [BasicHttpBindingServiceMetadataExchangeEndpoint]
 [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
 public class Service : IService
 {
 public string HelloWorld()
 {
 return "Hello World de mon service WCF dans SharePoint 2013";
 }
 }
}

Ouvrir le fichier IService.cs et y insérer le code suivant :

using System.ServiceModel;

namespace POC.SharePoint.WebServiceHelloWord.ISAPI.WebServiceHelloWord
{
 [ServiceContract]
 public interface IService
 {
 [OperationContract]
 string HelloWorld();
 }
}

Ouvrir le fichier Service.svc et y insérer le code suivant :

<%@ ServiceHost Language="C#" Debug="true"
 Service="POC.SharePoint.WebServiceHelloWord.ISAPI.WebServiceHelloWord.Service, $SharePoint.Project.AssemblyFullName$"
 CodeBehind="Service.svc.cs"
 Factory="Microsoft.SharePoint.Client.Services.MultipleBaseAddressBasicHttpBindingServiceHostFactory,
 Microsoft.SharePoint.Client.ServerRuntime,
 Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

Étape 6 – Permettre à VS d’effectuer le remplacement des tokens dans un fichier *.svc

Dans le code du dernier fichier Service.svc qu’on a ajouté il y a une ligne contenant un jeton de remplacement (Token) : $SharePoint.Project.AssemblyFullName$

Si on ne fait rien on aura une erreur lors de la compilation. Il y a plusieurs façon de s’y prendre mais à mon avis la façon la plus élégante est de permettre à VS d’effectuer le remplacement de ces tokens pour les fichiers « *.svc ». J’appel cette technique la passe du coyote qui tousse!

Pour s’y faire, on doit effectuer un « Unload Projet » et ensuite un « Edit {NomDuProjet}.csproj ».

Ensuite trouver la ligne suivante :

<SandboxedSolution>False</SandboxedSolution>

Après cette ligne ajouter celle-ci :

<TokenReplacementFileExtensions>svc</TokenReplacementFileExtensions>

Sauvegarder le fichier et faire un « Reload project ».

Étape 7 – Compiler, déployer et tester le service WCF (REST) personnalisé

Une fois que vous aurez compilé et déployé votre service, vous pourrez le tester directement par son URL : http://serveur/_vti_bin/WebServiceHelloWord/Service.svc

testWcf

Cliquez ici pour télécharger le code source

Autres cas d’utilisations

Bien évidemment, le message retourné par notre fonction « HelloWorld » ne nous apporte rien de concret mais voici quelques exemples d’utilisation que l’on peut faire avec un service Web WCF (REST) personnalisé dans SharePoint :

  • Modifier les métadonnées d’un document (Ex: Ajouter un préfixe)
  • Exporter un rapport personnalisé en PDF
  • Modifier la sécurité d’un élément
  • Envoyer un document en pièce jointe d’un courriel
  • etc…

Conclusion

Utiliser un service Web WCF (REST) personnalisé dans SharePoint comporte plusieurs avantages comparativement à utiliser une page « aspx » avec une WebPart. D’une part, le service est accessible plus facilement via « _vti_bin » dans tout les sites et lorsqu’on utilise un service web WCF on envoie seulement le XML nécessaire au lieu d’envoyer tout le contenu HTML d’une page « aspx ».

Un bottin dans SharePoint qui s’alimente de l’AD?

Introduction

Dans tout bon intranet, il y a un bottin téléphonique pour permettre aux utilisateurs de rechercher leur collègues soit par leur nom ou prénom à l’intérieur d’une même entreprise. Les gens de communications vous le dirons, c’est une des fonctionnalités les plus utilisées si l’information est fiable et que le tout est simple d’utilisation. Trop souvent, une liste SharePoint est créé et utilisé comme un bottin téléphonique et malheureusement cette liste n’est pas mise-à-jour régulièrement. En plus de dupliquer le contenu entre l’AD et SharePoint, cela peut créer une incohérence lorsque l’information diffère entre les deux endroits. L’idéal c’est d’avoir l’information à jour dans l’AD et de s’en servir comme source principale. Ensuite, on peut s’alimenter de l’AD ou se synchroniser à partir de l’AD pour avoir un bottin téléphonique mis-à-jour régulièrement.

Il existe plusieurs solutions pour y arriver et dans ce billet que je vais tenter d’éclairer vos lanternes en vous proposant 2 solutions :

1. En utilisant la recherche de personne et en s’alimentant du service des profils utilisateurs (UPS)

C’est probablement la meilleure solution car elle est évolutive et native. En plus de cela, il y a la possibilité d’avoir d’autres propriétés propres à chaque individu (ex. : compétences, langues, expertises, etc.). De plus, on peut alimenter les profils utilisateurs avec l’information provenant d’autres systèmes (ex. : Système de RH).

En quoi ça consiste ?

  • Mise en place du service de profil utilisateur (UPS);
  • Synchronisation du service de profil utilisateur avec l’AD;
  • Configuration de la recherche de personnes;
  • Création des pages du bottin qui effectuent des requêtes sur le service de profil utilisateur via le service de recherche.

Exemple :

sharepoint-people-directory

2. En utilisant une WebPart pour l’affichage et en s’alimentant de l’AD

Si vous n’envisagez pas d’avoir un site MySite et de configurer les services applicatifs requis, cette solution est probablement votre meilleure alternative. Elle est peu coûteuse mais elle n’offre pas tout les avantages de la première solution avec le service des profils utilisateurs et la recherche.

En quoi ça consiste ?

  • Installation d’une WebPart gratuite;
  • Configuration de la WebPart pour se connecter à l’AD;
  • Personnalisation de l’affichage de la WebPart (Au besoin).

Exemple :

UsersADBrowser

Source :  http://usersadbrowser.codeplex.com/

Masquer ou ne pas masquer le ruban dans SharePoint, telle est la question

Lorsqu’on parle du ruban on parle bien sur de cette barre d’outil qui s’affiche par défaut dans le haut de chaque page dans SharePoint. SharePoint introduit le ruban pour aider les utilisateurs à accomplir leurs tâches. L’une des idées derrière le ruban, c’est qu’il soit toujours à la portée de sorte que les utilisateurs peuvent facilement découvrir les fonctionnalités dont ils ont besoin à un moment donné. Voici un aperçu du ruban (SharePoint 2010) :

rubban1

Lorsque viens le temps de personnaliser l’aspect visuel d’un site SharePoint les designeurs web ont tendance à exclure le ruban de leurs maquettes. Pourquoi ? C’est fort simple, ce sont souvent des firmes de design externe qui sont mandaté pour faire les maquettes de site SharePoint et celle ayant SharePoint dans leur portefolio sont peu nombreuse. Ils n’aiment pas que leur créativité soit brimé et ils ne sont pas très chaud à l’idée d’avoir une barre de boutons dans le haut en permanence.

Sites de publication

Ils ont un bon point, dans la mesure où l’ont veut créer une maquette pour un site de publication et que la majorité des utilisateurs n’effectuent pas de modification au contenu alors le ruban n’est pas un pré-requis. Il faut tout de même prévoir un mécanisme facile pour afficher le ruban afin que les super-utilisateurs puissent modifier leurs pages.

Sites de collaboration

Cependant, dans un site de collaboration, je considère que c’est une problématique de masquer le ruban car on enlève l’accès facile aux fonctionnalités contextuel.

Récente SharePointerie avec le ruban

J’ai récemment eu à intervenir sur une problématique relié au ruban dans un site d’équipe chez un client. Leur ruban était masqué par défaut de manière temporaire dans la page maitre et il était possible de l’afficher à l’aide d’un bouton « Afficher le ruban / Masquer le ruban ». Bien évidemment, c’est après plusieurs heures de débogage de JavaScript que je me suis rendu compte de la cause du problèmes.

Problématique / symptômes :

Lorsqu’on utilise le menu contextuel dans une bibliothèque de documents d’un site d’équipe et qu’ensuite on affiche le ruban, les boutons du ruban ne fonctionnent plus.

Cause du problème :

Dans une bibliothèque de documents lorsqu’on navigue dans un dossier SharePoint met l’onglet « Document » par défaut mais il n’y arrive pas à le faire si le ruban est masqué (Par la page maître).
Détails technique :

J’ai testé avec la page maitre par défaut et bien évidemment je n’avais pas le problème car le ruban est visible par défaut. Ensuite, c’est en analysant les URL des bibliothèques que je me suis rendu compte qu’en enlevant le paramètre « InitialTabId » le ruban fonctionnait à nouveau.

Ex : http://UrlDuSite/NomBibliotheque/Forms/AllItems.aspx?RootFolder=NomDuDossier&FolderCTID=LeGuidDuDossier&InitialTabId=Ribbon%2EDocument

Par défaut lorsqu’on navigue dans un « dossier » d’une bibliothèque de document le paramètre « InitialTabId » est ajouté dans le URL.

Solution :

Cesser de masquer le ruban par défaut dans la page maitre.

Meilleures pratiques

Comme les meilleures pratiques le suggère, vous n’êtes pas censé cacher le ruban de manière permanente puisque la plupart des fonctionnalités de SharePoint sont accessibles par ruban facilement. Si malgré tout, vous voulez le masquer de manière temporaire, soyez à l’affut des éventuelles problématiques.

Conclusion

En bref, je ne vous recommande de ne pas masquer le ruban dans un site de collaboration car ceci peut occasionner des erreurs telles que démontré dans la SharePointerie ici-haut. En plus de cela,  ça peut créer des incohérences si un comportement est différent entre les utilisateurs et les super-utilisateurs. Cependant, pour un site de publication qui serait modifié par quelques utilisateurs c’est très envisageable de le masquer pour avoir un visuel avec du tape à l’œil.