SharePoint 2010 propose de nouvelles manières de développer un modèle de site personnalisé :
Développement d’une définition de site
Pas de changement majeur par rapport à la version 2007, une définition de site impose toujours de déployer un fichier webtemp.xml en plus du fichier onet.xml. Pour SharePoint 2010, Visual Studio 2010 propose un type et un élément de projet spécifique pour créer une définition de site.
Génération à la souris d’un modèle de site
Je parle ici du modèle de site généré automatiquement lorsque l’on utilise la fonctionnalité “Enregistrer en tant que modèle de site” de la page des paramètres d’un site.
Avec SharePoint 2010, cela génère un package .wsp de type solution sandbox (en 2007, cela générait un .stp qui avait certaines limitations).
On peut éventuellement le réutiliser dans une autre ferme et/ou l’importer dans Visual Studio 2010 pour y effectuer des modifications. Malheureusement en l’important dans Visual Studio 2010, on constatera qu’un projet initié sur cette base serait difficilement maintenable car tous les éléments de base y sont redéfinis. On notera toutefois que le modèle de site généré est un WebTemplate.
Développement d’un WebTemplate
Nouveauté SharePoint 2010, l’élément de feature WebTemplate permet de créer un modèle de site en “héritant” d’une définition de site. Cet élément peut être de scope Farm ou Site. En cas de scope Site, il peut être déployé dans une solution sandbox.
L’héritage en question n’est que déclaratif : on devra fournir un onet.xml qui sera utilisé par SharePoint au moment de la création d’un site. Suite à sa création, l’onet.xml sera “oublié” et le site sera considéré comme ayant été créé avec la définition de site “héritée”.
A mon sens, l’intérêt majeur de cette nouveauté est la facilité qu’elle apportera lors de la migration vers la prochaine version de SharePoint. Chaque site existant créé via un WebTemplate bénéficiera des traitements de migration prévus par l’équipe produit pour la définition de site dont il hérite.
Pour développer un WebTemplate, l’approche consiste donc à fournir un onet.xml minimal dans lequel on référence des features de scope web. Passer par des features plutôt que par des éléments xml dans l’onet facilite la maintenance et garantie une meilleure portabilité en cas de migration puisque migrer des features sera en principe plus aisé que de migrer une définition de site.
On regrettera juste que Visual Studio 2010 n’en propose pas la création d’une manière automatique, contrairement aux définitions de sites.
Voici un récapitulatif des avantages et inconvénients des 3 méthodes :
|
Avantages |
Inconvénients |
Définition de site |
- Modèle de projet dans Visual Studio 2010
|
|
Modèle de site |
- Création par un utilisateur avancé
- Migration automatique
- Sandbox Solution
|
|
WebTemplate |
- Migration automatique
- Maintenance facile
- Sandbox ou Farm Solution
- Déployé en feature (donc activable/désactivable)
|
- Limitation (contournable, voir plus bas) sur l’activation des features de collection de sites référencées dans la balise <SiteFeatures> de l’onet.xml
|
Voyons maintenant comment développer un modèle de site avec un WebTemplate.
Développement d’un WebTemplate
Dans Visual Studio 2010, créer un projet SharePoint vide (ou charger un projet SharePoint existant) puis y ajouter un “Empty SharePoint Item” nommé WebTemplate_ClientMeetings.
Dans le fichier elements.xml généré, ajouter la définition suivante :
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<WebTemplate Name="WebTemplate_ClientMeetings"
BaseConfigurationID="1"
BaseTemplateName="STS"
BaseTemplateID="1"
Title="Rendez-vous clients"
Description="Site de gestion de rendez-vous clients"
DisplayCategory="Demo"
Locale="1036"
/>
</Elements>
Cette définition indique que l’on crée un modèle de site “Rendez-vous clients” qui “hérite” du modèle de site “Site vierge” (STS#1).
Attention, l’attribut Name doit correspondre au nom du répertoire dans la structure du projet, car il s’agit du nom du répertoire dans lequel SharePoint s’attendra à trouver le fichier onet.xml.
Copier maintenant le fichier …14\TEMPLATE\SiteTemplates\STS\XML\ONET.XML dans le même répertoire.
Sélectionner ensuite le fichier onet.xml dans la structure du projet et indiquer le mode de déploiement “ElementFile”.

On peut maintenant faire le ménage dans notre onet.xml afin de ne garder que ce qui nous intéresse, et ajouter les features que l’on souhaite activer. Dans l’exemple, WebTemplate a un attribut BaseConfigurationID="1", on peut donc ne conserver que la configuration ayant l’attribut ID="1".
Voici contenu de mon fichier onet.xml :
<?xml version="1.0" encoding="utf-8"?>
<Project Title="$Resources:onet_TeamWebSite;" Revision="2" ListDir="$Resources:core,lists_Folder;" xmlns:ows="Microsoft SharePoint" UIVersion="4">
<Configurations>
<Configuration ID="1" Name="Blank" MasterUrl="_catalogs/masterpage/v4.master">
<SiteFeatures>
<!-- BasicWebParts Feature -->
<Feature ID="00BFEA71-1C5E-4A24-B310-BA51C3EB7A57" />
<!-- Three-state Workflow Feature -->
<Feature ID="FDE5D850-671E-4143-950A-87B473922DC7" />
</SiteFeatures>
<WebFeatures>
<!-- TeamCollab Feature -->
<Feature ID="00BFEA71-4EA5-48D4-A4AD-7EA5C011ABE5" />
<!-- MobilityRedirect -->
<Feature ID="F41CC668-37E5-4743-B4A8-74D1DB3FD8A4" />
<!-- WikiPageHomePage Feature -->
<Feature ID="00BFEA71-D8FE-4FEC-8DAD-01C19A6E4053" />
<!-- Apply_MasterPage -->
<Feature ID="3805d5ae-b975-4652-a644-0f0578a25e1b" />
</WebFeatures>
</Configuration>
</Configurations>
</Project>
Dans cet exemple sont référencées les mêmes features que dans la définition de site parente, plus la feature des pages wiki et une feature custom permettant d’appliquer une master page spécifique.
Une fois déployé, un nouvel modèle de site devrait alors apparaitre dans l’écran de création de site :

Une limitation importante à connaitre
Mon projet exemple est composé de 3 features :
- Farm_WebTemplate (scope Farm) : la feature qui contient mon élément WebTemplate
- Site_MasterPage (scope Site) : via un module, elle provisionne la master page personnalisée dans la galerie des master pages de la collection de sites
- Web_ApplyMasterPage (scope Web) : par code, elle applique la master page personnalisée au site courant
La limitation est la suivante : lorsque l’on crée un site en se basant sur un modèle de site WebTemplate, les features de niveaux collection de sites ne sont pas activées automatiquement. Si dans <SiteFeatures> on en référence une qui n’est pas activée, on aura le message d’erreur suivant lors de la création du site :

Pour contourner ce problème, une solution consiste à activer par code la feature de scope Site dans le receiver de la feature Web_ApplyMasterPage, et de ne référencer que la feature de scope Web dans l’onet.xml.
Ci-dessous le code exécuté à l’activation de la feature Web_ApplyMasterPage, qui se charge de l’activation de Site_MasterPage :
Pour plus d’informations sur l’élément WebTemplate, je vous invite à consulter l’article de Vesa Juvonen : SharePoint 2010 and web templates
Arnault Nouvel
Winwise
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :