Déploiement de solutions de personnalisation pour les sites SharePoint 2010 à l’aide de solutions en bac à sable
Résumé : découvrez comment créer des solutions de personnalisation compatibles avec le bac à sable à l’aide de pages maîtres, de fichiers CSS et d’images personnalisés, en vue de les déployer sur des batteries de serveurs Microsoft SharePoint 2010.
Dernière modification : mardi 16 août 2011
S’applique à : Business Connectivity Services | Office 2010 | Open XML | SharePoint Designer 2010 | SharePoint Foundation 2010 | SharePoint Online | SharePoint Server 2010 | Visual Studio
Dans cet article
Vue d’ensemble
Pertinence du bac à sable
Création du projet Branding101
Conclusion
Ressources supplémentaires
À propos de l’auteur
Contenu
Vue d’ensemble
Pertinence du bac à sable
Création du projet Branding101
Conclusion
Ressources supplémentaires
.jpg "Cliquez pour récupérer le code")
Téléchargez l’exemple de code à partir de la bibliothèque de code MSDN (éventuellement en anglais)
Les Outils de développement SharePoint dans Microsoft Visual Studio 2010 offrent une approche simple et efficace de l’empaquetage et du déploiement des fichiers et du code nécessaires à l’application d’une personnalisation aux sites Microsoft SharePoint 2010 à l’aide d’une solution en bac à sable (sandbox). Cet article décrit une meilleure pratique pour la création de solutions de personnalisation compatibles avec le bac à sable à l’aide de pages maîtres, de feuilles de style en cascade (fichiers CSS) et d’images personnalisées, en vue de les déployer sur des batteries de serveurs SharePoint 2010 qui exécutent SharePoint Foundation 2010 ou SharePoint Server 2010.
Il existe une seule façon de déployer une solution métier développée pour la version précédente des produits et technologies SharePoint. Une solution SharePoint qui cible une batterie de serveurs Windows SharePoint Services 3.0 ou Office SharePoint Server 2007 doit être déployée au niveau de la batterie de serveurs par un administrateur de batterie. Le déploiement de solutions de batterie de serveurs requiert l’extension des fichiers personnalisés aux serveurs Web frontaux, ce qui entraîne certains risques pour l’intégrité de la batterie de serveurs. En outre, la plupart des solutions de batterie de serveurs installent des DLL d’assembly personnalisé dans le Global Assembly Cache sur le serveur Web, ce qui permet au code contenu de s’exécuter en bénéficiant d’une confiance totale. Par conséquent, de nombreux administrateurs de batterie imposent aux solutions SharePoint des révisions de code approfondies et des procédures de test strictes avant qu’elles puissent être déployées sur une batterie de serveurs SharePoint. Dans certains environnements SharePoint, les administrateurs de batterie vont plus loin en empêchant totalement le déploiement de solutions SharePoint au niveau de la batterie de serveurs.
SharePoint 2010 introduit une nouvelle architecture de mise en bac à sable qui peut tout à fait être utilisée à la place du déploiement au niveau de la batterie de serveurs. À la différence du déploiement de solutions de batterie de serveurs, le déploiement de solutions en bac à sable ne requiert pas un administrateur de batterie. En effet, une solution SharePoint développée en tant que solution en bac à sable peut être téléchargée et activée par un utilisateur professionnel au sein de l’étendue d’une collection de sites. Cela peut accélérer de manière significative le processus de mise en service d’une solution SharePoint personnalisée. En outre, les solutions en bac à sable vous permettent de développer des solutions SharePoint personnalisées dans Visual Studio 2010 destinées à des environnements qui n’autorisent pas le déploiement de solutions de batterie de serveurs, tels que SharePoint Online.
La nouvelle architecture de mise en bac à sable présente un aspect important dont vous devez avoir pleinement conscience. La conception et le développement de solutions SharePoint compatibles avec le bac à sable étendent vos options de déploiement. En effet, vous pouvez déployer en tant que solution en bac à sable ou que solution de batterie de serveurs une solution SharePoint qui a été développée de manière à cibler le bac à sable. Le simple fait de développer une solution SharePoint en tant que solution en bac à sable ne signifie pas que vous devez systématiquement la déployer en tant que solution en bac à sable.
Cet article contient un exemple qui illustre toute la souplesse que peut apporter une solution en bac à sable. Dans une batterie de serveurs SharePoint qui n’autorise pas le déploiement de solutions au niveau de la batterie de serveurs, les utilisateurs peuvent télécharger et activer votre solution SharePoint dans le contexte d’une collection de sites. Dans une autre batterie de serveurs SharePoint qui n’impose pas ces restrictions, la même solution SharePoint peut être déployée en tant que solution de batterie de serveurs, ce qui permet d’atteindre des niveaux de performance et de maintenabilité plus élevés. D’où l’intérêt de privilégier systématiquement une conception qui cible le bac à sable lorsque les contraintes de celui-ci ne vous empêchent pas d’accomplir ce que vous souhaitez.
De nombreuses techniques de développement SharePoint ne peuvent pas être utilisées lorsque vous développez des solutions en bac à sable. Par exemple, une solution en bac à sable ne peut pas déployer de fichiers au sein du répertoire racine de SharePoint ou dans tout autre emplacement sur le système de fichiers du serveur Web. Cela signifie que vous ne pouvez pas déployer de fichiers de personnalisation sur des emplacements habituels couramment utilisés dans les solutions de batterie de serveurs, tels que le répertoire IMAGES ou LAYOUTS. À la place, vous devez mettre en service les fichiers de personnalisation, tels que les images et les fichiers CSS, dans la base de données de contenu au sein de l’étendue de la collection de sites d’hébergement.
Lorsque vous écrivez du code pour une solution en bac à sable, il existe d’autres limitations à prendre en compte. Bien que vous puissiez accéder au modèle objet côté serveur de SharePoint Foundation 2010, les fonctionnalités disponibles dans une solution en bac à sable sont assez limitées par rapport aux fonctionnalités disponibles lorsque vous écrivez du code dans une solution de batterie de serveurs.
En règle générale, la conception de haut niveau d’une solution en bac à sable commence par l’ajout d’un ou de plusieurs Composants fonctionnels. Lorsque vous ajoutez un Composant fonctionnel à une solution en bac à sable, vous pouvez activer le Composant fonctionnel au niveau du site ou de la collection de sites. Toutefois, une solution en bac à sable ne peut pas contenir un Composant fonctionnel activé au niveau de la batterie de serveurs ou de l’application Web.
Lorsque vous commencez à développer des solutions en bac à sable, il est important de différencier les Composants fonctionnels activés au niveau de la collection de sites des Composants fonctionnels activés au niveau du site. En effet, un Composant fonctionnel configuré pour être activé au niveau de la collection de sites est automatiquement activé lorsque l’utilisateur active la solution en bac à sable qui le renferme. À l’opposé, les Composants fonctionnels configurés pour être activés au niveau du site ne sont pas automatiquement activés. Ils doivent être activés manuellement par l’utilisateur ou être activés à l’aide d’un code personnalisé. C’est la raison pour laquelle vous devez généralement concevoir une solution en bac à sable qui comporte au moins un Composant fonctionnel configuré pour être activé au niveau de la collection de sites. Cela vous permet de contrôler le moment auquel l’utilisateur active votre solution en bac à sable.
Vous pouvez ajouter un récepteur de fonctionnalité à un Composant fonctionnel dans une solution en bac à sable, de la même manière que vous pouvez le faire pour une solution de batterie de serveurs. Toutefois, gardez à l’esprit que le code que vous écrivez pour un récepteur de fonctionnalité dans une solution en bac à sable s’exécute au sein du service de code en mode bac à sable SharePoint Foundation et est soumis aux contraintes de l’architecture de mise en bac à sable. Heureusement, vous pouvez accéder aux fonctionnalités essentielles du modèle objet côté serveur qui vous permettent de configurer tous les sites d’une collection de sites de manière à ce qu’ils utilisent des pages maîtres personnalisées et des fichiers CSS personnalisés.
Lorsque vous créez une solution SharePoint pour personnaliser un site SharePoint 2010, vous devez déployer des fichiers personnalisés tels que des pages maîtres, des fichiers CSS et des images. Lorsque vous créez une solution en bac à sable, vous ne pouvez pas vous appuyer sur les techniques couramment utilisées dans les solutions de batterie de serveurs, techniques qui permettent de déployer les fichiers personnalisés dans le répertoire racine de SharePoint sur le système de fichiers du serveur Web. À la place, vous devez mettre en service les instances de ces fichiers à partir de modèles de fichier à l’aide de l’Module, élément (Module).
Par exemple, supposons que vous souhaitez déployer une page maître nommée MyCustomLayout.master au sein de la galerie de pages maîtres dans le site de niveau supérieur. Vous pouvez commencer par créer un Composant fonctionnel dont l’étendue est définie au niveau de la collection de sites. Ensuite, vous pouvez ajouter au répertoire des Composants fonctionnels un fichier de modèle nommé MyCustomLayout.master qui contient la disposition HTML de votre solution de personnalisation. Enfin, vous ajoutez un manifeste d’élément contenant l’élément Module suivant qui met en service une instance de MyCustomLayout.master dans la galerie de pages maîtres.
<Elements xmlns="https://schemas.microsoft.com/sharepoint/">
<Module Name="MasterPageGallery" Url="_catalogs/masterpage" >
<File Url="MyCustomLayout.master" Type="GhostableInLibrary" >
<Property Name="UIVersion" Value="4" />
<Property Name="ContentTypeId" Value="0x010105" />
</File>
</Module>
</Elements>
Lorsque vous créez un élément Module tel que celui-ci pour mettre en service des fichiers dans une bibliothèque de documents, telle que la galerie de pages maîtres, il est important de configurer l’attribut Url de l’élément Module à l’aide du chemin d’accès relatif de site de la racine de la bibliothèque de documents. Lorsque vous mettez en service une page maître dans la galerie de pages maîtres, l’attribut Url de l’élément Module doit toujours être configuré avec le chemin d’accès standard _catalogs/masterpage.
Lorsque vous mettez en service un fichier dans l’étendue d’une bibliothèque de documents, chaque File, élément (Module) doit contenir un attribut Type dont la valeur est GhostableInLibrary, comme le montre l’exemple de code précédent. Lorsque vous mettez en service des pages maîtres dans SharePoint 2010, vous devez également ajouter deux éléments Property à l’élément File pour configurer deux propriétés importantes nommées UIVersion et ContentTypeId.
SharePoint Foundation utilise la propriété UIVersion d’une page maître pour différencier les pages maîtres conçues pour l’interface utilisateur de SharePoint 2010 de celles conçues pour l’ancienne interface utilisateur de Office SharePoint Server 2007. Si vous concevez votre page maître à partir de l’interface utilisateur de SharePoint 2010, vous devez configurer la propriété UIVersion en lui affectant la valeur 4. Vous pouvez attribuer à la propriété UIVersion la valeur 3 dans les scénarios de mise à niveau visuelle lorsque vous avez conçu la page maître à partir de l’ancienne interface utilisateur.
La propriété ContentTypeId permet de différencier les pages maîtres et les mises en page utilisées par les sites de publication SharePoint Server 2010. Lorsque vous déployez une page maître, vous devez la configurer avec la valeur ContentTypeId adéquate pour les pages maîtres, en l’occurrence 0x010105.
Dans Office SharePoint Server 2007, les fonctionnalités de publication créent une bibliothèque de documents spéciale, nommée « Bibliothèque de styles », qui permet à Microsoft de déployer des fichiers CSS et des fichiers image standard qui sont utilisés dans les sites de publication. En outre, la bibliothèque de styles est couramment utilisée comme cible de déploiement par les développeurs et les concepteurs de sites Web qui appliquent des éléments de personnalisation aux sites de publication Office SharePoint Server 2007 à l’aide de fichiers CSS et de fichiers image.
Lorsque vous développez une solution de personnalisation générique et réutilisable pour des batteries de serveurs SharePoint Server 2010, vous ne pouvez pas utiliser la bibliothèque de styles, car elle n’existe que dans les sites de publication. Windows SharePoint Services 3.0 ne crée pas la bibliothèque de styles lorsque vous créez d’autres types de sites, tels qu’un site d’équipe, un site vide ou un espace de travail du document. Heureusement, cela n’est plus un problème dans SharePoint 2010.
Dans SharePoint 2010, chaque collection de sites possède sa propre bibliothèque de styles. En effet, Microsoft a déplacé les instructions de mise en service standard relatives à la création de la bibliothèque de styles depuis les fonctionnalités de publication vers la définition de site globale. Chaque fois que SharePoint Foundation 2010 crée une collection de sites, il ajoute la bibliothèque de styles au site de niveau supérieur. Cela fait de la bibliothèque de styles un candidat idéal pour le déploiement des fichiers CSS et des fichiers image dans une solution de personnalisation générique.
À présent, il est temps de parcourir les étapes de la création d’une solution de personnalisation générique à l’aide de Outils de développement SharePoint dans Visual Studio 2010. Vous pouvez commencer par créer un projet SharePoint vide nommé Branding101, comme le montre la figure 1.
Figure 1. Nouveau projet SharePoint vide
.gif "Nouveau projet SharePoint vide")
Lorsque vous créez le projet SharePoint, l’Assistant Personnalisation de SharePoint vous invite à fournir une URL d’un site de test SharePoint local et à sélectionner Déployer en tant que solution bac à sable (sandbox) ou Déployer en tant que solution de batterie pour le test. Veillez à sélectionner Déployer en tant que solution bac à sable (sandbox), comme le montre la figure 2.
Figure 2. Déployez en tant que solution en bac à sable
.gif "Déployez en tant que solution en bac à sable")
La première étape de la création d’une solution de personnalisation spécifique consiste à créer une page maître personnalisée. Commencez par créer un élément de projet Module qui permet de déployer la page maître personnalisée dans la galerie de pages maîtres.
Dans Visual Studio 2010, dans l’Explorateur de solutions, cliquez avec le bouton droit sur le nœud de projet Branding101. Dans le menu Projet, sélectionnez Ajouter, puis Nouvel élément.
Dans la boîte de dialogue Ajouter un nouvel élément, créez un élément de projet Module nommé MasterPageGallery, comme le montre la figure 3.
Figure 3. Module MasterPageGallery
.gif "Modèle MasterPageGallery dans Visual Studio")
Une fois le module créé, celui-ci contient un manifeste d’élément nommé Elements.xml et un exemple de fichier d’élément nommé Sample.txt. Cliquez avec le bouton droit sur le fichier Sample.txt, puis renommez-le Branding101.master, comme le montre la figure 4.
Figure 4. Élément de projet MasterPageGallery
.gif "Élément de projet MasterPageGallery")
La prochaine étape consiste à modifier le contenu du fichier de modèle Branding101.master avec le point de départ d’une page maître personnalisée. Une technique courante consiste à copier et à coller le texte à partir de la page maître SharePoint 2010 standard nommée v4.master. Utilisez l’Explorateur Windows pour rechercher le fichier de modèle v4.master, dont le chemin d’accès est le suivant.
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\GLOBAL\v4.master
Une fois que vous avez trouvé le fichier de modèle v4.master, ouvrez-le et copiez son contenu dans le Presse-papiers. Ensuite, ouvrez le fichier de modèle Branding101.master dans votre projet et supprimez tout son contenu. Collez le contenu du fichier v4.master dans le fichier Branding101.master, puis enregistrez vos modifications. Après avoir correctement copié le contenu du fichier de modèle v4.master, fermez celui-ci sans enregistrer les modifications.
Actuellement, votre page maître personnalisée possède le même contenu que la page maître SharePoint 2010 standard v4.master. À ce stade, il est opportun d’apporter au moins une modification rapide à Branding101.master afin de pouvoir visuellement identifier le fait que votre page maître personnalisée est en cours d’utilisation. Pour ce faire, vous pouvez rechercher la balise de corps ouvrante dans Branding101.master et ajouter l’élément suivant immédiatement après celle-ci.
<div style="background-color:yellow">Branding101.master</div>
Votre page maître personnalisée étant maintenant créée, vous devez modifier le fichier Elements.xml dans le module MasterPageGallery pour qu’il soit correctement déployé dans la galerie de pages maîtres pendant l’activation du Composant fonctionnel. Ouvrez le fichier Elements.xml et mettez à jour l’élément Module et son élément File interne avec le contenu XML suivant.
<Elements xmlns="https://schemas.microsoft.com/sharepoint/">
<Module Name="MasterPageGallery"
Path="MasterPageGallery"
Url="_catalogs/masterpage" >
<File Url="Branding101.master" Type="GhostableInLibrary" >
<Property Name="UIVersion" Value="4" />
<Property Name="ContentTypeId" Value="0x010105" />
</File>
</Module>
</Elements>
À ce stade, vous avez terminé votre travail initial sur le module MasterPageGallery. Vous devez maintenant porter votre attention sur le Composant fonctionnel qui sera utilisé pour déployer ce module. Notez que lorsque vous avez ajouté le module au projet Branding101, les Outils de développement SharePoint dans Visual Studio 2010 ont automatiquement créé un Composant fonctionnel nommé Feature1. Recherchez ce Composant fonctionnel dans l’Explorateur de solutions, cliquez dessus avec le bouton droit et attribuez-lui le nom Main.
Après avoir renommé le Composant fonctionnel, double-cliquez sur le nœud du Composant fonctionnel afin que celui-ci apparaisse dans le concepteur de Composant fonctionnel. Attribuez au Composant fonctionnel un titre plus approprié, tel que Exemple de Composant fonctionnel de personnalisation 101, comme le montre la figure 5. Il est également important de modifier l’étendue du Composant fonctionnel de Web en Site afin qu’il soit activé au niveau de la collection de sites et non au niveau du site.
Figure 5. Exemple de Composant fonctionnel de personnalisation 101 dans le concepteur de Composant fonctionnel
.gif "Concepteur de fonctionnalités")
Une fois que vous avez créé une page maître personnalisée, l’étape suivante consiste à ajouter un fichier CSS personnalisé qui contient les règles CSS associées à votre solution de personnalisation. Comme indiqué précédemment, il est particulièrement recommandé dans SharePoint 2010 de déployer les fichiers CSS personnalisés dans la bibliothèque de styles, car cela fonctionne avec les solutions en bac à sable et solutions de batterie de serveurs. Cette technique fonctionne dans les batteries de serveurs qui exécutent SharePoint Server 2010 et également dans les batteries de serveurs qui n’exécutent que SharePoint Foundation. Notez que de nombreuses autres approches courantes de la personnalisation des sites SharePoint 2010 n’offrent pas ce niveau de souplesse.
Dans l’Explorateur de solutions, cliquez avec le bouton droit sur le nœud de projet Branding101 et, dans le menu Projet, sélectionnez Ajouter, puis Nouvel élément.
Dans la boîte de dialogue Ajouter un nouvel élément, créez un élément de projet Module nommé Style Library, comme le montre la figure 6.
Figure 6. Module Style Library
.gif "Module de bibliothèque de styles")
Le nouvel élément de projet Module contient initialement un manifeste d’élément nommé Elements.xml et un exemple de fichier d’élément nommé Sample.txt. Cliquez avec le bouton droit sur le fichier Sample.txt et attribuez-lui le nom Styles.css.
Ensuite, cliquez avec le bouton droit sur le nœud de module Style Library et, dans le menu Projet, sélectionnez Ajouter, puis Nouveau dossier pour créer un nouveau dossier enfant dans le module Style Library. Attribuez au dossier le nom Branding101.
Après avoir créé ce dossier, vous pouvez déplacer le fichier styles.css en le faisant glisser vers le dossier dans l’Explorateur de solutions.
Figure 7. Fichier Styles.css dans le module Style Library
.gif "Fichier Styles.css dans l’Explorateur de solutions")
Après avoir déplacé le fichier styles.css dans le dossier Branding101, ouvrez le fichier, puis supprimez la totalité de son contenu. Ensuite, ajoutez une règle CSS simple pour la balise de corps et vérifiez qu’IntelliSense fonctionne correctement. Ajoutez l’attribut padding-top suivant afin de pouvoir visuellement identifier le fait que la liaison à ce fichier CSS est correctement établie.
body {
padding-top: 50px;
}
La prochaine étape consiste à ajouter certains fichiers image au projet. La meilleure approche consiste à ajouter vos fichiers image personnalisés à la bibliothèque de styles afin qu’ils soient plus faciles à référencer à partir de votre fichier CSS personnalisé. Dans le dossier Branding101, créez un dossier Images, puis ajoutez certains fichiers image à ce dossier. Cet exemple utilise deux images : un fichier image, nommé Background.jpg, fait office d’image d’arrière-plan récurrente pour le corps de la page, tandis qu’une seconde image nommée Logo.gif fait office de logo du site.
Figure 8. Fichiers Image dans la bibliothèque de styles
.gif "Images de site")
Après avoir ajouté les fichiers image au dossier Images, vous pouvez facilement les référencer à partir des règles CSS dans styles.css. À titre d’illustration, ajoutez les mises à jour suivantes au fichier styles.css afin d’utiliser Background.jpg comme image d’arrière-plan récurrente pour le corps de la page.
body {
padding-top: 50px;
background-image: url('Images/Background.jpg');
background-repeat: repeat;
}
À ce stade, vous avez achevé votre travail initial avec la bibliothèque de styles. À la différence du module MasterPageGallery que vous avez créé précédemment, le fichier Elements.xml ne requiert de votre part aucune modification manuelle. Les Outils de développement SharePoint dans Visual Studio 2010 peuvent automatiquement ajouter tous les éléments File appropriés en arrière-plan. En outre, vous pouvez continuer à ajouter des fichiers image au dossier Images, qui seront automatiquement déployés à l’emplacement adéquat dans la bibliothèque de styles.
Maintenant que vous avez ajouté deux éléments de projet Module pour déployer une page maître personnalisée et un fichier CSS personnalisé, il est temps d’écrire du code pour les appliquer. Pour ce faire, vous ajoutez un récepteur de fonctionnalité au Composant fonctionnel Main. Dans l’Explorateur de solutions, cliquez avec le bouton droit sur le nœud du Composant fonctionnel Main, puis sélectionnez Ajouter un récepteur d’événements pour ajouter une classe de récepteur de fonctionnalité.
Figure 9. Ajouter un récepteur d’événements
.gif "Ajouter un récepteur d’événements")
Dans la classe de récepteur de fonctionnalité, vous devez substituer et implémenter deux méthodes nommées FeatureActivated(SPFeatureReceiverProperties) et FeatureDeactivating(SPFeatureReceiverProperties). Commencez votre codage en nettoyant et en restructurant le fichier source de votre classe de récepteur de fonctionnalité afin qu’il ressemble à l’exemple suivant.
using System;
using System.Runtime.InteropServices;
using Microsoft.SharePoint;
namespace Branding101.Features.Main {
[Guid("cc5874a5-695b-49d2-9cd2-4fa12be83874")]
public class MainEventReceiver : SPFeatureReceiver {
public override void FeatureActivated(
SPFeatureReceiverProperties properties) {
// TODO: add activation code here.
}
public override void FeatureDeactivating(
SPFeatureReceiverProperties properties) {
// TODO: add deactivation code here.
}
}
}
À présent, examinons la procédure que vous devez suivre lorsque le Composant fonctionnel principal est activé. Tout d’abord, vous devez déterminer le chemin d’accès de la page maître Branding101.master dans la galerie de pages maîtres de manière à pouvoir configurer des sites qui s’appuient sur cette page maître. Notez que le chemin d’accès de la page maître doit être calculé par rapport à la racine de l’application Web d’hébergement. Ensuite, vous devez énumérer tous les sites dans la collection de sites actuelle et mettre à jour plusieurs propriétés de chaque site afin d’utiliser la page maître personnalisée et le fichier CSS personnalisé. L’implémentation suivante de la méthode FeatureActivated(SPFeatureReceiverProperties) met à jour les propriétés SPWeb requises pour chaque site.
public override void FeatureActivated(
SPFeatureReceiverProperties properties) {
SPSite siteCollection = properties.Feature.Parent as SPSite;
if (siteCollection != null) {
SPWeb topLevelSite = siteCollection.RootWeb;
// Calculate relative path to site from Web Application root.
string WebAppRelativePath = topLevelSite.ServerRelativeUrl;
if (!WebAppRelativePath.EndsWith("/")) {
WebAppRelativePath += "/";
}
// Enumerate through each site and apply branding.
foreach (SPWeb site in siteCollection.AllWebs) {
site.MasterUrl = WebAppRelativePath +
"_catalogs/masterpage/Branding101.master";
site.CustomMasterUrl = WebAppRelativePath +
"_catalogs/masterpage/Branding101.master";
site.AlternateCssUrl = WebAppRelativePath +
"Style%20Library/Branding101/Styles.css";
site.SiteLogoUrl = WebAppRelativePath +
"Style%20Library/Branding101/Images/Logo.gif";
site.UIVersion = 4;
site.Update();
}
}
}
La propriété MasterUrl de l’objet SPWeb vous permet de rediriger les pages de site et d’application vers une page maître personnalisée, telle que Branding101.master. L’exemple de code précédent calcule le chemin d’accès de Branding101.master en combinant le chemin d’accès relatif d’application Web du site et le chemin d’accès relatif de site de la galerie de pages maîtres dans le site de niveau supérieur, dont la valeur est systématiquement _catalogs/masterpage.
Notes
Cet exemple met à jour la propriété SPWeb nommée CustomMasterUrl en plus de la propriété MasterUrl. La mise à jour de la propriété CustomMasterUrl n’est importante que dans les sites de publication dont la bibliothèque de documents Pages contient des pages de publication. La propriété CustomMasterUrl permet de réaffecter la page maître pour les pages de publication. L’affectation d’une nouvelle valeur à la propriété CustomMasterUrl dans un site SharePoint Foundation n’a aucune incidence et n’engendre aucun problème.
La propriété AlternateCssUrl permet de lier les pages d’un site au fichier CSS personnalisé nommé Styles.css. Le comportement de liaison associé à la propriété AlternateCssUrl est implémenté par le contrôle CssLink SharePoint, qui est défini dans la section d’en-tête de toutes les pages maîtres SharePoint 2010 standard. En outre, le contrôle CssLink SharePoint ajoute un lien vers un fichier CSS essentiel appelé CoreV4.css et doit, par conséquent, être inclus dans toute page maître personnalisée qui cible SharePoint 2010.
Bien que la solution de personnalisation dans cet article repose sur la méthode de liaison à un fichier CSS personnalisé par le biais de la propriété AlternateCssUrl, gardez à l’esprit que certaines solutions de personnalisation recourent à une autre méthode de liaison à un fichier CSS personnalisé, qui fait appel au contrôle CSSRegistration. Par exemple, vous pouvez ajouter l’élément CssRegistration suivant à la section d’en-tête d’une page maître personnalisée pour établir une liaison à un fichier CSS dans la bibliothèque de styles.
<SharePoint:CssRegistration
name="<% $SPUrl:~sitecollection/Style Library/styles.css %>"
After="corev4.css"
runat="server"
/>
Un avantage du contrôle CssRegistration par rapport à la propriété AlternateCssUrl est qu’il vous permet d’établir une liaison à plusieurs fichiers CSS. Un second avantage est que vous pouvez recourir au contrôle CssRegistration dans des pages spécifiques lorsqu’un fichier CSS est utilisé par une partie seulement des pages d’un site. Toutefois, l’utilisation du contrôle CssRegistration présente un inconvénient en ce sens qu’il repose sur l’expression $SPUrl, ce qui suppose que la batterie de serveurs d’hébergement exécute SharePoint Server 2010. Si votre solution de personnalisation est appelée à être utilisée dans des batteries de serveurs qui n’exécutent que SharePoint Foundation, vous devez privilégier la technique de liaison à un fichier CSS personnalisé par le biais de la propriété AlternateCssUrl au détriment de l’utilisation du contrôle CssRegistration.
La propriété SiteLogoUrl est utilisée dans cet exemple, car elle permet de remplacer rapidement et efficacement l’image du site dans le coin supérieur gauche de la page. Notez que le comportement associé à la propriété SiteLogoUrl est implémenté par le contrôle SiteLogoImage SharePoint, qui est défini dans la section de ligne de titre des pages maîtres SharePoint 2010 standard, telles que v4.master.
La propriété UIVersion permet de définir si le site actuel doit s’exécuter en mode interface utilisateur pour les sites SharePoint 2010 ou dans l’ancien mode interface utilisateur, utilisé lors de la migration de sites Office SharePoint Server 2007 vers SharePoint 2010. Le principal effet de la définition de la propriété UIVersion est qu’elle détermine si le contrôle CssLink est lié au nouveau fichier CSS standard créé pour SharePoint 2010 et nommé corev4.css ou à l’ancien fichier CSS standard nommé core.css, qui permet de définir le style des pages dans Office SharePoint Server 2007. L’exemple de cet article attribue la valeur 4 à la propriété UIVersion afin que les pages soient liées à corev4.css et non à core.css.
À ce stade, vous savez comment et pourquoi la solution Branding101 configure des propriétés SPWeb importantes sur chaque site de la collection de sites actuelle pendant l’activation du Composant fonctionnel. Cette section décrit le code qui doit être exécuté pendant la désactivation du Composant fonctionnel. Il est opportun de supprimer tous les éléments de personnalisation pour rétablir la collection de sites actuelle dans son état initial.
L’exemple suivant est une implémentation de la méthode FeatureDeactivating qui amène toutes les pages à utiliser la page maître standard v4.master et qui supprime le lien vers le fichier CSS personnalisé et vers le logo de site personnalisé.
public override void FeatureDeactivating(
SPFeatureReceiverProperties properties) {
SPSite siteCollection = properties.Feature.Parent as SPSite;
if (siteCollection != null) {
SPWeb topLevelSite = siteCollection.RootWeb;
// Calculate relative path of site from Web Application root.
string WebAppRelativePath = topLevelSite.ServerRelativeUrl;
if (!WebAppRelativePath.EndsWith("/")) {
WebAppRelativePath += "/";
}
// Enumerate through each site and remove custom branding.
foreach (SPWeb site in siteCollection.AllWebs) {
site.MasterUrl = WebAppRelativePath +
"_catalogs/masterpage/v4.master";
site.CustomMasterUrl = WebAppRelativePath +
"_catalogs/masterpage/v4.master";
site.AlternateCssUrl = "";
site.SiteLogoUrl = "";
site.Update();
}
}
}
Vous devez ajouter un élément de projet pour terminer le projet Branding101. Il vous manque un dispositif permettant d’appliquer automatiquement vos éléments de personnalisation aux sites enfants lorsqu’ils sont créés dans une collection de sites qui a activé le Composant fonctionnel Branding101. Pour effectuer cette opération dans Windows SharePoint Services 3.0 ou Office SharePoint Server 2007, vous devriez utiliser l’association de fonctions. Toutefois, SharePoint 2010 prend en charge un nouvel événement appelé WebProvisioned, qui facilite sensiblement cette tâche.
Dans l’Explorateur de solutions, cliquez avec le bouton droit sur le nœud de projet Branding101 et, dans le menu Projet, sélectionnez Ajouter, puis Nouvel élément. Dans la boîte de dialogue Ajouter un nouvel élément, créez un élément de projet Récepteur d’événements nommé ChildSiteInit.
Lorsque vous créez un élément de projet Récepteur d’événements, l’Assistant Personnalisation de SharePoint vous invite à sélectionner le type souhaité. Sélectionnez un récepteur d’événements de type Événements Web. En bas de la boîte de dialogue, sous Gérer les événements suivants, sélectionnez l’option Un site a été configuré.
Figure 10. Assistant Personnalisation de SharePoint
.gif "Un site a été mis en service")
Lorsque vous cliquez sur Terminer, les Outils de développement SharePoint dans Visual Studio 2010 ajoutent un nouveau gestionnaire d’événements nommé WebProvisioned, ainsi qu’un fichier Elements.xml, qui contient l’élément Receivers nécessaire à l’inscription de ce gestionnaire d’événements dans la collection de sites actuelle. L’avantage de l’ajout de cet événement est que celui-ci se produit à chaque création d’un site enfant. Cela permet assez facilement d’écrire le code qui copie les propriétés SPWeb appropriées depuis le site de niveau supérieur vers le nouveau site enfant. Le code nécessaire est le suivant.
using System;
using Microsoft.SharePoint;
namespace Branding101.ChildSiteInit {
public class ChildSiteInit : SPWebEventReceiver {
public override void WebProvisioned(
SPWebEventProperties properties) {
SPWeb childSite = properties.Web;
SPWeb topSite = childSite.Site.RootWeb;
childSite.MasterUrl = topSite.MasterUrl;
childSite.CustomMasterUrl = topSite.CustomMasterUrl;
childSite.AlternateCssUrl = topSite.AlternateCssUrl;
childSite.SiteLogoUrl = topSite.SiteLogoUrl;
childSite.Update();
}
}
}
Le travail de développement sur le projet Branding101 est maintenant terminé. En résumé, le projet SharePoint a été structuré à l’aide de quatre éléments de projet principaux :
Premièrement, vous avez ajouté un module avec une page maître personnalisée et vous l’avez configuré de manière à mettre en service une instance de cette page maître dans la galerie de pages maîtres.
Deuxièmement, vous avez ajouté un module qui cible la bibliothèque de styles de manière à mettre en service une instance d’un fichier CSS personnalisé et de plusieurs fichiers image.
Troisièmement, vous avez ajouté un récepteur de fonctionnalité avec du code pour énumérer tous les sites de la collection de sites actuelle et configurer les propriétés SPWeb pour chaque site afin d’établir une liaison à votre page maître personnalisée et à votre fichier CSS personnalisé.
Enfin, vous avez ajouté un récepteur d’événements pour initialiser automatiquement les nouveaux sites enfants avec les caractéristiques de personnalisation nécessaires.
Votre projet final doit maintenant être structuré comme indiqué dans la figure 11.
Figure 11. Projet final dans l’Explorateur de solutions
.gif "Projet Branding101 dans l’Explorateur de solutions")
L’heure est venue de tester votre travail. Dans l’Explorateur de solutions, cliquez avec le bouton droit sur le nœud de projet Branding101, puis cliquez sur Déployer. Visual Studio 2010 génère votre projet en un package de solution nommé Branding101.wsp. Ensuite, Visual Studio télécharge le package de solution de sortie du projet vers la galerie de solutions de votre site de test et l’active. Une fois le déploiement terminé, vous devez être en mesure d’accéder à votre site de test et de vérifier qu’il utilise désormais votre page maître personnalisée et votre fichier CSS personnalisé.
Figure 12. Site de test
.gif "Site de test")
Bien que votre travail de développement soit terminé, votre travail de conception ne fait que commencer. Vous devez maintenant modifier votre page maître et votre fichier CSS de manière à créer une solution à l’aspect séduisant. Si vous le souhaitez, vous pouvez continuer à utiliser Visual Studio 2010 pour concevoir votre page maître et votre fichier CSS.
Lorsque vous modifiez la page maître et le fichier CSS dans Visual Studio 2010, vous pouvez tester votre travail facilement. Par exemple, apportez une légère modification à la disposition HTML dans Branding101.master ou à une règle CSS dans styles.css. Ensuite, réexécutez la commande Déployer, puis actualisez la page actuelle dans le navigateur pour voir l’impact de vos modifications.
Il existe une autre technique de conception très utile dont vous devez tenir compte, qui consiste à intégrer SharePoint Designer 2010 dans votre travail conceptuel. Par exemple, vous pouvez ouvrir votre site de test à l’aide de SharePoint Designer 2010, puis ouvrir la page maître Branding101.master en mode de modification avancée. Le gros avantage de cette approche est que SharePoint Designer 2010 procure une expérience de conception de page maître pour les sites SharePoint beaucoup plus riche que tout autre dispositif dans Visual Studio 2010. En outre, SharePoint Designer 2010 est pratique à plus d’un titre pour la modification des fichiers CSS.
Vous devez avoir à l’esprit que SharePoint Designer ne vous permet pas de modifier directement les modèles des pages maîtres, telles que Banding101.master, ou les modèles des fichiers CSS, tels que styles.css. À la place, lorsque vous travaillez dans SharePoint Designer 2010, vous apportez des modifications de personnalisation aux instances mises en service qui sont stockées dans la base de données de contenu. Toutefois, cela ne constitue pas véritablement un problème, car il vous suffit de savoir effectuer des opérations copier-coller entre SharePoint Designer 2010 et Visual Studio 2010.
Une fois que vous avez apporté des modifications à la conception d’une page maître dans SharePoint Designer 2010, il vous suffit de copier dans le Presse-papiers le contenu de la page maître personnalisée en mode code. Ensuite, revenez à Visual Studio 2010 et collez le contenu du Presse-papiers dans le fichier de modèle de Branding101.master. Vous pouvez utiliser la même méthode pour copier le contenu personnalisé de styles.css depuis SharePoint Designer et le coller dans la version de modèle de styles.css dans Visual Studio 2010.
Désormais, vous bénéficiez véritablement du meilleur des deux mondes. Vous pouvez utiliser la puissance de SharePoint Designer 2010 pour créer une solution de personnalisation à l’aspect séduisant. Vous avez aussi la possibilité d’empaqueter votre travail de personnalisation en un package de solution en vue de son déploiement en tant que solution en bac à sable ou en tant que solution de batterie de serveurs dans n’importe quelle batterie de serveurs exécutant SharePoint Foundation ou SharePoint Server 2010.
Pour plus d’informations, consultez les ressources suivantes :
Prise en main des outils de développement SharePoint 2010 dans Visual Studio 2010
Channel 9 : solutions en bac à sable (éventuellement en anglais)
.jpg "Collaborateur MVP")
Ted Pattison est auteur, formateur et cofondateur de Critical Path Training (éventuellement en anglais), une société spécialisée dans la formation sur les technologies SharePoint. En tant que Most Valuable Professional (MVP) sur Microsoft SharePoint, Ted travaille souvent avec le groupe Developer Platform Evangelism de Microsoft pour effectuer des recherches et créer de la documentation de formation SharePoint pour les développeurs en amont du cycle de vie du produit, dans les phases des versions alpha ou bêta. Ted est également co-auteur de Inside Microsoft SharePoint 2010 (éventuellement en anglais).