download.microsoft.comdownload.microsoft.com/.../2009/CoachSPDevAtelier02.docx · Web viewCes...

Microsoft Créer votre propre modèle de site SharePoint : un Site Definition– Atelier 2

Coach Sharepoint 2007

< Atelier 2 />Créer votre propre modèle de site

SharePoint : un Site Definition

Printemps 2009 Tutoriel Découverte de SharePoint 2007 sur 41


Sommaire

1 INTRODUCTION......................................................................................................................................................3

1.1 CONTEXTE FONCTIONNEL........................................................................................................................31.2 CONTEXTE TECHNIQUE............................................................................................................................4

2 INTRODUCTION ET DÉCOUVERTE D’UN SITE DEFINITION....................................................................6

2.1 PRÉSENTATION SIMPLIFIÉ:.......................................................................................................................62.2 LE MODÈLE GLOBAL.............................................................................................................................92.3 LE VIRTUAL PATH PROVIDER (PAGE CUSTOMIZED VS UNCUSTOMIZED)..............................................102.4 QUAND FAUT-IL CRÉER UN SITE DEFINITION ?......................................................................................13

3 CRÉEZ VOTRE PROPRE « SITE DEFINITION » SHAREPOINT.................................................................14

3.1 MISE EN PLACE D’UNE SOLUTION DE TRAVAIL SOUS VISUAL STUDIO POUR UN SITE DEFINITION.......153.1.1 Préparation de votre machine de travail...........................................................................153.1.2 Création d’une solution.....................................................................................................15

3.2 PERSONNALISER LE MODÈLE DE SITE.....................................................................................................203.2.1 Découverte du ONET.XML du modèle STS......................................................................213.2.2 Personnalisation du nœud <Configuration/>.....................................................................243.2.8 Tester & déployer votre modèle de site............................................................................35

4 POUR ALLER PLUS LOIN…................................................................................................................................38

5 RENDEZ-VOUS DANS LE PROCHAIN ATELIER….......................................................................................39



1 IntroductionCet atelier s’inscrit dans le cadre du tutoriel de découverte du développement avec la technologie SharePoint 2007. L’objectif est la réalisation d’un modèle de site entièrement personnalisé avec la méthodologie expliquée pas à pas.

Les exercices de l’atelier N°2 vous permettront d'étendre votre plateforme SharePoint en créant votre propre modèle de site ou "Site Definition", base de toute création de nouveau site. Vous parcourrez ainsi le modèle XML de conception SharePoint : le CAML ainsi que les quelques astuces de conception.

1.1 Contexte fonctionnel

Rappel du contexte fonctionnel du Tutoriel de découverte de la technologie SharePoint 2007

L’objectif du tutoriel est de construire pas à pas un site personnalisé SharePoint incluant les grands axes de développement SharePoint tel que

Création d’un modèle de site avec son design et sa charte graphique Ajout de fonctionnalités déclaratives par les « Features ». Ajout de fonctionnalités associées avec des événements de code .Net Composants WebPart Son Packaging et Déploiement complets

Contexte fonctionnel de l’atelier 2 dans le cadre du Tutoriel

L’objectif est de découvrir la conception et la réalisation d’un véritable modèle de site SharePoint.

Comme nous avons vu dans le premier tutoriel, la base de la technologie SharePoint, en dehors de ses services métiers, est de proposer une véritable usine à créer et gérer de multiples sites Web. En résumé, favoriser l’industrialisation des sites d’une entreprise.

A cet effet, il existe dans toute ferme SharePoint, un ensemble de modèles de site permettant de générer au besoin des sites tels que :

Des sites d’équipes Des blogs Des wikis Un portail communicant …



La création de vos propres modèles métiers est donc un des principaux axes de personnalisation possibles, elle est même souvent à la base de bien des projets sous cette technologie.

1.2 Contexte technique

Un modèle de site SharePoint ou « Site Definition » définit clairement au moteur SharePoint l’ensemble des opérations et fichiers pour générer virtuellement une nouvelle instance de celui-ci.

En pratique, il s’agit d’une collection de fichiers XML basée sur le métalangage XML, le CAML

Les modèles de sites sont hautement personnalisables du fait qu’ils sont à la base même de la génération des sites SharePoint. Cependant, si l’XML facilite la compréhension des fichiers, l’étendue des possibilités, la richesse du schéma CAML est loin de rendre cette opération des plus aisées.

La tâche n’est pas pour autant complexe si vous vous appuyez sur quelques bons reflexes et bonnes pratiques, que nous allons couvrir le long de cet atelier.

A la fin, vous saurez comment :

Créer votre propre modèle de site multilingue Monter une solution de développement SharePoint pour vous faciliter sa conception Utiliser un style, une Master Page et des pages personnalisées Découvrir quelques facettes du langage CAML

Soit en pratique :

1. Introduction et découverte d’un Site Definition Présentation simplifiée Le modèle GLOBAL Etat Customisé / Non Customisé Par l’exemple, le modèle Team Site ou site d’équipe

2. Conception d’une solution de développement Visual Studio : Préparation et configuration de l’outil Création du projet et des scripts de travail Clonage du site d’origine

3. Personnalisation de votre site Ajout d’une Master Page personnalisée Ajout d’une Page personnalisé



Ajout de WebPart

Cet atelier se base sur l’utilisation de la technologie SharePoint 2007 via son offre de base Windows SharePoint Services V3 (WSS).

Note :



2 Introduction et découverte d’un Site DefinitionDans cet exercice, vous allez découvrir :

- La composition d’un modèle de site SharePoint.- Les différents concepts utilisés par le moteur de génération.- Le rôle des différents fichiers et références

ObjectifL’objectif de ce chapitre est de vous permettre de mieux appréhender le contenu des fichiers XML et ASPX composant un modèle de site SharePoint. Vous pourrez ainsi, aisément créer vos propres modèles et décomposer ceux existants

Contexte fonctionnel

Comme nous l’avons vu lors du premier atelier, SharePoint 2007 est avant tout un moteur de génération de sites SharePoint ; il repose exclusivement sur l’utilisation et la personnalisation des « Site Definitions ».

La plupart des fichiers XML utilisés dans ces modèles reposent sur le métalangage XML dit le CAML. Bien comprendre les astuces, les fragments de code XML des sections principales de ce langage vous permettront de comprendre et d’utiliser au maximum le potentiel de SharePoint.

En effet, 80% de la puissance du moteur SharePoint reposent sur ces fichiers de description XML qui vous permettent de générer vos sites SharePoint métiers sans la moindre ligne de code à compiler.

2.1 Présentation simplifié:

Le but de ce tutoriel est clairement de vous assister dans la découverte des Site Definition, Dés lors, nous ne pourrons couvrir l’ensemble des possibilités et du potentiel de ceux-ci. Cette présentation simplifiée va surtout s’attacher à vous présenter les points les plus importants des modèles de génération de site SharePoint.

Les Site Definitions sont à la source de tous les modèles de site utilisables dans SharePoint 2007. Il s’agit d’une collection de fichiers XML ainsi que les divers fichiers ASP.NET composant le site comme les CSS, les Master Pages et les pages ASPX. Ils sont associés directement à la notion de « Site Provisionning » ou génération de site.

Ils définissent réellement le site SharePoint comme sa construction ASP.NET ainsi que son modèle de stockage. Les listes comme les contacts ou les bibliothèques documentaires, les nombres et les instances de celle-ci ainsi que leur contenu peuvent être déclarés dans ces modèles afin de créer des sites vraiment prêts à l’emploi. Printemps 2009 Tutoriel Découverte de SharePoint 2007 sur 41


Clairement, la création de modèles vraiment métier, proche des besoins business des utilisateurs et, de plus, évolutif, est une des forces premières de la plateforme SharePoint.

Une fois un site créé, il devient totalement indépendant de son modèle d’origine. C’est un peu le principe d’un pochoir si l’on devait prendre une image. Les sites peuvent ainsi être modifiés et personnalisés en termes de contenu par l’ajout de listes ou de rendus graphiques via SharePoint Designer, par exemple.

Meme si le site existe indépendamment, il est bien relié à son modèle d’origine ; cette référence est permanent et ne peut être changée. C’est un des points fondamentaux des outils de gestion et de maintenance des sites de la ferme. Nous entrerons plus en details dans d’autres tutoriels mais par exemple, si une sauvegarde d’une collection de sites est restaurée sur une autre ferme ne possédant pas le site definition de l’un des sites, l’opération ne peut qu’échouer.

Avant de rentrer dans les détails, il est bon de bien positionner le modèle de site SharePoint et sa conception. Le Langage CAML est un des piliers historiques de la technologie SharePoint depuis la première version avec SharePoint Team System. Il a évolué avec le temps et a perduré dans les versions 2001, 2003 et 2007. Si le schéma est loin d’être simple en ce qui concerne le rendu Web mais moins dans le cas de la conception de site, il faut cependant, bien reconnaitre les véritables performances du parseur CAML associé au moteur de génération.

En effet, tout utilisateur voulant créer un site SharePoint depuis l’administration patiente rarement plus de 10 secondes pour créer de toutes pièces un nouvel espace de travail, une fois le modèle de site sélectionné et le bouton « valider » appuyé.

Qu’est ce que le langage CAML ?CAML = Collaborative Application Markup LanguageC’est, en fait, un schéma XML utilisé surtout dans la technologie SharePoint. Il permet de décrire en XML, la conception d’un modèle de site SharePoint. Qu’il s’agisse d’un simple site, d’une liste, d’une fonctionnalité et même les vues de données. Du fait des nombreuses possibilités de génération, ce schéma est très riche et très structuré, d’où une certaine complexité dans son utilisation. En développement, la sous-partie dédiée au filtre des données est très souvent utilisée afin de décrire des requêtes sur des jeux de données précis.

Il ne faut pas avoir de (vraies) inquiétudes en ce qui concerne le schéma CAML. Microsoft a ajouté, avec la version 2007, les différents schémas XSD utilisé dans la technologie SharePoint. Ils sont stockés dans le fameux répertoire 12 dans le sous dossier « 12/Template/XML ». Le schéma correspondant au CAML est représenté par le fichier wss.xsd

SharePoint 2007 a su apprendre et évoluer des anciennes versions et aussi des différents retours d’expérience des clients et des communautés. La création des modèles sous les anciennes versions de SharePoint était plus que spartiate et souvent bien problématique car le moindre modèle de site représentait plus de 2500 nœuds XML !



Dans la version 2007, la nouvelle structure des modèles de site a été revue afin de privilégier la réutilisation et la fragmentation XML

Ainsi, l’architecture des Site Definition a été volontairement dispersée en différents concepts, loin de tout modèle autonome :

1. Des fichiers de base communs Ils correspondent à un ensemble de sous fichier XML qui définissent les grands types de base de tout site SharePoint comme les type de colonnes, le schéma à créer en base de données ou encore, les références des icones ou le paramétrage régional par exemple. En voici quelques uns comme FLDTYPES.XML, DOCICON.XML, BASE.XML, …

2. Le modèle source de tout site : le GLOBAL Le « Site Definition » GLOBAL est utilisé dans toute création de nouveau site SharePoint. Il centralise tout les concepts ainsi que les éléments de base supportant la génération des sites. Il gère, par exemple, la création des galeries principales comme celles de WebPart ou des profiles. Ainsi, il permet de se concentrer uniquement sur le contenu métier que l’on doit intégrer dans son propre « Site Definition »

3. Les fichiers de déclaration les « Site Definitions » sont indépendants de leur déclaration dans le moteur de génération. Ainsi, divers manifestes XML et leurs ressources de langues permettent de les configurer indépendamment de leur propre contenu technique.

En pratique, un modèle de site est composé de plusieurs 3 fichiers de base :a. Le WebTemp*.xml

C’est le contrat de définition et d’utilisation du modèle de site dans l’interface de génération de SharePoint. Il gère aussi la déclaration du site pour le multilinguisme.

b. ONET.xmlCe fichier contient l’ensemble de la configuration CAML d’un site SharePoint depuis les barres de navigation, aux listes utilisé jusqu’au différentes WebParts utilisées à l’accueil d’un site

c. Les composants physiquesc’est l’ensemble des fichiers web comme les fichiers « .master » ou pages aspx à utiliser lors de la génération des sites

A chaque modèle correspond un sous dossier dans le répertoire 12/TEMPLATE/SiteTemplates comme pour l’exemple du site d’équipe : STS

4. Les fonctionnalités réutilisables : les Features

Les Features sont des fragments d’un Site Definition mais avec leurs propres éléments déclaratifs et zones d’action. Ainsi, une Feature installée dans une ferme SharePoint peut très bien être réutilisée sur différents « Site Definition ». Ils facilitent ainsi la maintenance et la création de nouveaux modèles ainsi que la réutilisation de fonctionnalités avancées.

Les « Features » ou fonctionnalités sont un des fondements (fondamentaux) de la personnalisation et l’extensibilité de SharePoint 2007. Ce sont des composants à base d’XML définissant tout nouvelle option ou paramétrage d’un site SharePoint.



Nous ne détaillerons pas les Features dans ce tutoriel car c’est un sujet vraiment important que l’on se doit de parcourir de très près. Ce sera d’ailleurs le sujet principal des 2 prochains tutoriels.

Les fichiers de types sont considérés comme des fichiers systèmes de SharePoint. Microsoft conseille vivement de ne pas les modifier afin de garantir leur fonctionnement.

De maniére générale, l’ensemble des fichiers présents dans le fameux répertoire « 12 » ne sont pas censés être modifiés ou alterés. En effet, la garantie produit de Microsoft ne couvre votre plateforme que si, et seulement si, ces fichiers dit systémes restent identiques à ceux de l’installation. Comme d’ailleurs le schéma des bases de données attachées aussi. Les tests de performance et de stabilite de SharePoint ont été établis avec cette version des fichiers et du fait de leur role central dans le fonctionnement de l’ensemble, il est donc evident que leur modification peut être réellement dangeureuse. Cependant, leur découverte, leur composition et les techniques utilisées peuvent être largement formatrice..

2.2 Le modèle GLOBAL.

Le modèle GLOBAL est à la base de création de tout site web SharePoint. Il centralise l’ensemble des éléments de génération représentant le cœur même du fonctionnement d’un site.

Il faut bien comprendre que ce modèle représente un peu les fondations d’un site SharePoint. Il n’est en rien fonctionnel ou métier et n’a pas pour vocation d’évoluer. Il est là pour garantir que le site SharePoint possède toutes les bases techniques attendues pour fonctionner correctement.

Le modèle GLOBAL se trouve physiquement dans 12/TEMPLATE/GLOBAL. Il reprend la même structure physique et le schéma utilisés par les « Site Definitions » que nous allons couvrir dans le chapitre suivant.

D’un point de vue développeur, le modèle Global a aussi plusieurs intérêts : Il minore le risque d’ajout/suppression de samples XML importants dans un modèle de site Il globalise la base technique des sites SharePoint Il limite le travail du développeur au strict besoin métier du site SharePoint

En effet, comme chaque site fait référence au modèle global, il évite toute duplication hasardeuse de code inutile. Le modèle de site ne contiendra donc que les fonctionnalités et les spécificités du site comme prévu par les besoins utilisateurs.

Dés lors, le contenu du modèle global n’est pas une surprise, il ne contient que les composants fondamentaux d’un site SharePoint.

Un des premiers éléments définis dans le modèle GLOBAL, est la définition des 5 listes de base qui servent de galerie aux diverses collections de sites SharePoint comme :

La galerie des « Master Page » (MPLib) La galerie des « User info » (liste cachée de gestion des profils locaux des utilisateurs)



La galerie des « Site Template » (WebTemp, liste des modèles utilisateurs ou STP) La galerie des « WebParts » (WPLib) La galerie des « List Template » (Listtemp, liste des modèles de liste utilisateur, aussi au

format STP)

En ce qui concerne les fichiers physiques, ce modèle gère directement les 2 fichiers de master : default.master : il contient l’ensemble des contrôles de chargement et de publication des

sites SharePoint en dehors de ceux utilisant le modèle de réunionMwsdefault.master : ce fichier master contient justement les spécificités du modèle de meeting MPS

Comme le modèle GLOBAL est quasi identique, techniquement au le modèle d’un site classique, il permet de découvrir aisément de bons exemples d’implémentation CAML. En effet, le GLOBAL couvrant tout la base d’un site, il contient quasiment un sample de chaque possibilité de génération. Soit un terrain d’exploration propice à tout développeur souhaitant aller plus loin dans sa démarche.

Attention, il est important de respecter les scénarios supportés dans SharePoint en ce qui concerne le développement de modèle de site. Il ne faut pas modifier les fichiers du modèle Global ou de tout autre modèle déployé par l’installation d’origine.http://support.microsoft.com/kb/898631/fr L’utilisation des fichiers ASP.Net dans la génération de site SharePoint comme le fait le modèle GLOBAL utilise un mécanisme bien particulier. En effet, il ne s’agit pas d’une bête recopie du fichier dans le site mais d’une mise en cache pouvant gérer aussi bien les performances

2.3 Le Virtual Path Provider (page Customized vs uncustomized)

Faisons un petit retour en arrière : depuis 2001, chaque version de la technologie SharePoint a dû gérer la problématique des pages web dans la génération des sites.

Sous STS V1, a chaque création de site, les pages asp étaient dupliquées sur le disque dur du serveur. Système simple mais avec de véritables défauts en terme de maintenance et de montée en charge.

Sous WSS V2, Microsoft a introduit la notion de Ghosting. A chaque création de page, seules les metadata caractérisant la page étaient stockées dans la base de données du site. Les pages restaient dans le répertoire système, cependant, le filtre ISAPI pouvait les virtualiser dans le site en les recherchant puis en les exécutant dynamiquement sur la bonne url.

Un peu comme si la page existait sous forme d’une chimère mémoire, d’où le surnom donné à cette opération : « Ghosting ». Si jamais la référence en BDD était mauvaise, le parseur ne pouvait que se résoudre à afficher une erreur 404. Cependant, si les fichiers étaient mis à jour, les modifications étaient directement visibles dans les sites générés. Frontpage 2003 exploitait aussi ce système mais d’un autre point de vue. En effet, les modifications faites via cet outil enregistrait étaient enregistrées dans une image complète de la page dans la base de donnée et indiquait au moteur SharePoint de ne plus utiliser le fichier sur disque.

En technologie SharePoint, on parle de pages ASPX « » quand elles n’ont pas été modifiées via SharePoint Designer ou tout outil tiers après génération du site. Ces pages peuvent donc exploiter nativement le framework ASP.Net et le système de cache SharePoint. Les pages modifiées ou


http://support.microsoft.com/kb/898631/fr


« customized » sont stockées dans la base de données et fonctionnent de manière moins intégrée et moins performante.

Si le principe de Ghosting fonctionnait bien, il possédait intrinsèquement de vraies limitations en ce qui concernait les pages modifiés ou « unghostées » comme la non-gestion du cache et du JIT ASP.Net, la nécessite de récupérer la page via la BDD à chaque appel, ce qui avait un véritable impact sur les performances.

L’arrivée de ASP.Net 2.0 dans SharePoint 2007 a permis de garder certains des principes du « Ghosting » mais en bénéficiant directement des nouveautés du framework. Le principal changement a été une implémentation du framework .Net 2.0 au plus profond du moteur SharePoint ; ainsi, le filtre ISAPI a été supprimé au profit d’un HttpHanlder et de Httpmodule.

Introduction au HttpHanlderhttp://msdn.microsoft.com/en-us/library/ms227675.aspx

Introduction au HttpModulehttp://msdn.microsoft.com/en-us/library/ms178468.aspx

Ce changement est fondamental sur le moteur de rendu de SharePoint 2007. Désormais, le serveur IIS réagit de manière naturelle. Si un fichier ASPX existe dans un site IIS étendue par SharePoint, la page est toujours exécutable à son adresse naturelle. Il est donc bien plus facile d’intégrer des sites ASP.Net existants, tout en respectant cependant les spécificités de configuration de SharePoint évidemment.

En ce qui concerne les pages des modèles de site, celles-ci sont toujours virtualisées comme dans le cas du « Ghosting » mais via l’utilisation désormais d’un SPVirtualPathProvider.


http://msdn.microsoft.com/en-us/library/ms178468.aspx

http://msdn.microsoft.com/en-us/library/ms227675.aspx

http://msdn2.microsoft.com/



How to use virtual path providers to dynamically load and compile content from virtual paths in ASP.NET 2.0http://support.microsoft.com/kb/910441

Ce provider permet de faire une abstraction complète du stockage du fichier ASP.Net par rapport au runtime ASP.Net. Chaque site SharePoint possède donc une version virtuelle de sa page ASPX provenant soit du fichier physique du Site Definition (uncustomized) référencé dans la base de données ou de sa version modifiée par SharePoint Designer stocké en dans la base de données de contenu (customized).

Le format BLOB ou « Binary Large OBject » est un type de donnée permettant le stockage des données binaires. Il correspond sous SQL Server au type de champ BINARY ou IMAGE. La taille maximum autorisée sous SQL Server est de 2 Go de données binaire d’où les limitations sur les fichiers de SharePoint.

L’appel au Blob de la base de données est donc limité uniquement aux pages « customisées » ce qui évite de cloner les fichiers en base à chaque génération de site et favorise aussi le cache ASP.Net naturel.

En plus du SPVirtualPathProvider, l’implémentation des Master Pages permet aussi de centraliser une partie du rendu et des briques de base d’un site SharePoint, indépendamment des pages ASPX du site. Des lors, les pages du site qu’elles soient modifiées ou non, peuvent profiter d’une mise à jour directe du fichier de Master Page sur le disque dur.

Le fonctionnement « customized/uncustomized » permet ainsi de simplifier la maintenance de nombreux sites et leurs différences. Grâce à la centralisation unique des fichiers ASPX dans le modèle de site, Le déploiement des mises à jour des pages est ainsi bien plus aisé. De plus, il laisse aussi la liberté aux utilisateurs habilités de pouvoir modifier et personnaliser les pages de leur site via SharePoint Designer sans pour autant impacter sur la gestion de la ferme ou posséder des compétences de développeur SharePoint.

Attention, il est clair que les pages modifiées ou customized impactent directement les performances d’affichage de celles-ci. Si le résultat n’est pas grave dans le cas d’un simple site projet de 10 utilisateurs, ce n’est pas vraiment le cas pour la page d’accueil d’un portail groupe avec 500


http://support.microsoft.com/kb/910441



utilisateurs secondes. Il faut donc bien pondérer l’utilisation de SharePoint Designer dans la conception des sites web

Attention, les Master Pages fonctionnent elles aussi sur le même modèle que les pages ASPX. Elles peuvent être aussi modifiées via SharePoint Designer et devenir « customized ». Comme ces fichiers sont à la base de tout rendu graphique du site, il est important que celles-ci soient toujours « customized » pour garantir la performance globale du site

Il est bon d’intégrer les Master Pages d’un site directement dans son Site Definition à leur création et de proscrire l’ajout de Master par un simple téléchargement dans la galerie des master pages. L’upload ne crée pas d’état « uncustomized », à la différence d’un modèle de site ou d’une Feature

2.4 Quand faut-il créer un Site Definition ?

Les « Site Definitions » sont à la base de tout site SharePoint mais ils ne sont pas forcement la raison de tout projet sur cette plateforme. Leur création est une opération assez conséquente qu’il est bon de pondérer.

Voici quelques points types qui justifie cette pondération :

Il faut une mise en page et un style graphique bien particulier à votre site Il faut une navigation ainsi que certains composants métier spécifiques à votre site Le niveau de génération de votre site est au niveau ferme et non simplement un sous site web Il faudra de nombreuses instances de votre modèle de site (ex :espace projet) Le site contiendra des pages ainsi que des contenus spécifiques lors de la création du site Il faudra que le site puisse s’intégrer naturellement avec une application tierce ou propriétaire. …

A vrai dire, la seule vraie question est surtout de voir si les modèles de sites fournis par SharePoint peuvent répondre directement à votre besoin. Si ce n’est pas le cas, il vaut mieux créer votre propre modèle en se basant par exemple sur un modèle existant comme celui du site d’équipe (STS).

Il existe d’autres mécanismes pouvant personnaliser un modèle de site SharePoint comme l’utilisation de « Feature » par exemple. Nous couvrirons ce sujet lors du prochain atelier. Un point cependant, il faut minimiser les fonctionnalités couvertes par votre modèle de site afin de n’y placer que celles qui répondent à votre besoin. Tout ce qui peut être réutilisable ou indépendant devrait être fait sous forme de « Feature ».

Note :



3 Créez votre propre « Site Definition » SharePointDans cet exercice, vous allez apprendre à :

- Lire et comprendre un modèle de site SharePoint ;- Étendre un modèle de site existant ;- Implémenter :

o Une Master Page et une page personnaliséeo De nouvelles listes et du contenuo Des WebParts dans une page

ObjectifL’objectif de cet exercice est de créer un nouveau modèle de site SharePoint ainsi que de manipuler le flux CAML de leur manifest XML. Ce modèle illustrera quelques uns des « Best Practices » de modification de Site Definition

Contexte fonctionnelNous allons implémenter les bases d’un modèle de site qui pourraient vous servir comme base de travail à tous vos projets de site SharePoint. Nous commencerons par cloner le modèle de site le plus simple de la plateforme, soit le modèle d’équipe : STS.

Dans la découverte de ce modèle, nous modifierons sa configuration afin de pouvoir gérer un rendu et des contenus spécifiques en restant le plus fidèle à la philosophie collaborative de SharePoint.

Afin de respecter au mieux une démarche projet, nous nous placerons en situation en implémentant le tout dans une solution Visual Studio en détaillant la méthodologie utilisée.

Pour mieux comprendre le fonctionnement intrinsèque de la plateforme, ce chapitre et l’ensemble de ces exercices ne seront pas basés sur les extensions SharePoint pour Visual Studio.


MasterPage spécifique

Page spécifiqueWebPart de contenu

WebPart Image

Liste de document projet


Ces extensions créent une abstraction de la plateforme pour le développeur afin de lui faciliter le travail. L’objectif du Coach SharePoint étant de vous aider à découvrir et comprendre le fonctionnement de cette technologie, nous travaillerons au plus proche de celle-ci.

L’utilisation des extensions pour Visual Studio ainsi que des projets communautaires comme le WSPBuilder ou STSDev sont un vrai « plus » pour les développeurs. Nous ne pouvons que vous encourager à les découvrir une fois ces exercices réalisés.

3.1 Mise en place d’une solution de travail sous Visual Studio pour un Site Definition.

3.1.1 Préparation de votre machine de travail

Le précédant chapitre expliquait clairement l’intérêt de travailler directement depuis un Serveur SharePoint avec une installation de Visual Studio plutôt que sur un poste utilisateur sous XP ou Vista. En effet, il sera difficile de coder et tester un applicatif pour une plateforme SharePoint sans celui-ci. C’est à peu prés la même chose que de vouloir coder un site ASP.Net sans le framework .Net et sans serveur Web

Le meilleur compagnon du développeur SharePoint est souvent la machine virtuelle et Virtual PC 2007. Il vous suffit de créer une machine Windows Serveur avec une installation « Stand Alone » (attention, stand alone ok mais jamais par défaut, il faut installer le server SQL si on veut avoir une machine proche de la réalité) de SharePoint 2007 (celle-ci contient un script d’auto déploiement gérant la configuration ainsi que l’installation d’un serveur SQL Embedded !!!!!!!?????) et Visual Studio 2005. Un bon conseil : garder cette machine virtuelle propre en ne travaillant qu’a partir de disques différenciés pour chaque projet et éviter de cloner le disque a chaque besoinhttp://support.microsoft.com/kb/825092/fr

Virtual PC 2007http://www.microsoft.com/downloads/details.aspx?displaylang=fr&familyid=04d26402-3199-48a3-afa2-2dc0b40a73b6

3.1.2 Création d’une solution

La première phase de tout projet SharePoint est de pouvoir créer un environnement de développement facilitant la conception et la réalisation d’un modèle de site SharePoint. Composé de fichiers ASP.Net ainsi que de flux XML, Visual Studio est un outil idéal.

Comme nous l’avons vu dans le chapitre sur l’architecture de SharePoint 2007, l’ensemble des fichiers systèmes se trouve dans le fameux répertoire 12 de votre serveur. Pour faciliter la conception, nous utiliserons une arborescence similaire mais dans le projet Visual Studio.

Déroulement de l’exercice :


http://www.microsoft.com/downloads/details.aspx?displaylang=fr&familyid=04d26402-3199-48a3-afa2-2dc0b40a73b6

http://www.microsoft.com/downloads/details.aspx?displaylang=fr&familyid=04d26402-3199-48a3-afa2-2dc0b40a73b6

http://support.microsoft.com/kb/825092/fr



1. Ouvrir Visual Studio et créer un projet de développement de type Projet vide.

Nous allons créer un modèle de site que nous appellerons CoachSP

2. Reproduire l’arborescence du répertoire 12 nécessaire à notre projet via l’ajout de dossier dans l’explorateur Visual Studio

Il faut créer l’arborescence suivante

12 (le cœur système de SharePoint)o Ressources (pour gérer les fichiers de traduction Rex)o TEMPLATE (répertoire des modèles)

1033 (répertoire pour la zone US : 1033) 1036 (répertoire pour la zone FR : 1036) IMAGES (stockage des images) SiteTemplates (Stockage des « Site Definitions »)



CoachSP (Nom de votre projet de modèle de site)

Le nom du dossier dans SiteTemplates est très important car il est l’identifiant unique du modèle de site. Il sera réutilisé aussi bien dans les fichiers de configuration que dans le modèle objet en cas de création dynamique de site

3. Cloner le modèle de site STS

Il peut être particulièrement complexe de créer un modèle de site depuis un flux XML vierge même en s’appuyant sur le schéma XSD de SharePoint. L’idéal est souvent de partir d’un modèle de site collaboratif en copiant le contenu du répertoire du site, 12/TEMPLATE/SiteTemplates/STS

Une plateforme SharePoint WSS contient 4 « Site Definitions » de base qui sont disponibles par défaut pour créer de nouveaux sites. Il s’agit des 5 dossiers suivants de 12/TEMPLATE/SiteTemplates

STS (Site d’équipe, documentaire et vierge) MPS (site de meeting et variante) Blog WIKI

Ce modèle est composé d’un sous répertoire XML contenant le manifeste du « Site Definition » : le ONET.XML ainsi que les 2 pages ASPX servant d’accueil au site généré : default.aspx & defaultdws.aspx.

Dans un premier temps, nous ne copierons dans le répertoire « CoachSP » que le dossier XML et son fichier ONE.XML et le fichier Default.aspx.

Le fichier ONET.xml est le véritable cœur du « Site Definition », composé d’XML s’appuyant sur le Schéma CAML il définit entièrement la génération du site à pourvoir.

4. Déclarer le nouveau modèle

Pour que SharePoint puisse utiliser le modèle de site, il faut lui fournir des fichiers de déclaration. Ces fichiers doivent exister dans toutes les langues qui peuvent exploiter ce modèle.

Ces fichiers XML contiennent le titre, la description ainsi que l’icône représentant le modèle de site. Il est aussi possible de déclarer certains modèles comme cachés afin de limiter leur utilisation aux administrateurs en ligne de commande ou des processus tiers.

Les Fichiers WebTemp peuvent aussi contenir la déclaration d’une classe PortalProvisioningProvider qui gérera elle-même le processus de génération. Par exemple, le modèle Portail Collaboratif de MOSS utilise ce principe pour créer une arborescence de sites et sous sites au démarrage.

Ils se trouvent tous dans les répertoires de code de langue, « 12/TEMPLATE/[LCID]/XML » et sont au format suivant « WEBTEMP*.xml ». Au chargement applicatif, SharePoint parcoure l’ensemble de ces fichiers par code de langue et peut ainsi charger la liste complète des modèles disponibles pour les créateurs de site via cette interface



List of Locale ID (LCID) Values as Assigned by Microsofthttp://www.microsoft.com/globaldev/reference/lcid-all.mspx

Il est conseillé de créer un fichier WebTemp* par modèle de site que vous créez. Ainsi, vous ne risquez pas d’écraser un fichier du même nom sur une ferme existante

Dans le cadre de cet exercice nous allons déclarer notre modèle en français 1036 et anglais 1033 :

Code XML pour l’anglais : 12/TEMPLATE/1033/XML/WEBTEMP_CoachSP.xml<?xml version="1.0" encoding="utf-8" ?><Templates>

<Template Name="CoachSP" ID="14100"><Configuration ID="0"

Title="Coach SP site" Name="Default" Hidden="FALSE"

ImageUrl="/_layouts/images/CoachSP/image_site.PNG" Description="A sample site for the coach." DisplayCategory="Coach SP" >

</Configuration></Template>

</Templates>

Code XML pour le français: 12/TEMPLATE/1036/XML/WEBTEMP_CoachSP.xml<?xml version="1.0" encoding="utf-8" ?><Templates>

<Template Name="CoachSP" ID="14100"><Configuration ID="0"

Title="Site du Coach SP" Name="Default" Hidden="FALSE"


http://www.microsoft.com/globaldev/reference/lcid-all.mspx



ImageUrl="/_layouts/images/CoachSP/image_site.PNG"

Description="Un simple site pour le coach."

DisplayCategory="Coach SP" ></Configuration>

</Template></Templates>

On ajoutera pour finaliser une image « image_site.png » dans le répertoire « 12/TEMPLATE/IMAGES/CoachSP » afin de personnaliser la déclaration. Au niveau IIS, le sous répertoire « 12/TEMPLATE/IMAGES » existe à l’url « /_layouts/images »

Pour que le modèle de site soit pris en compte, il faut aussi lui donner un identifiant supérieur à 10 000. Microsoft réservant cette plage pour déployer ses propres modèles dans le futur. Dans le cadre de l’exercice, nous avons pris la valeur 14100 pour l’identifiant du Template

5. Déployer et tester votre modèle de site

Désormais, vous pouvez déployez votre modèle de site (cloné à partir du modèle STS). Le plus simple reste de recopier le répertoire 12 de votre projet dans celui de votre serveur.

Afin de faciliter la tache, il est très pratique de scripter l’opération avec un simple fichier CMD dans le répertoire Batchs de votre solution VS.Net :

Code de script pour le déploiement install.cmdcd ..@echo off

ECHO "-- FULL Deploy of the solution --"

@SET SPDIR="C:\program files\common files\microsoft shared\web server extensions\12"

xcopy 12\TEMPLATE %SPDIR%\TEMPLATE /s /yxcopy 12\RESOURCES %SPDIR%\RESOURCES /s /y

IISRESETPause

A noter que vous pouvez aussi ajouter cette ligne de commande dans les outils externes de Visual Studio :



Pour les développeurs chevronnés, il est aussi possible de déclarer cette ligne de commande dans l’événement PostBuild du projet et donc de profiter du fameux raccourci Ctrl+ F5

Voila, votre modèle est prêt et en ligne :

3.2 Personnaliser le modèle de site

Maintenant que notre modèle est prêt, nous pouvons nous consacrer à le personnaliser. Avant cela, découvrons un peu le contenu de l’ONET.XML du modèle STS que nous avons cloné.

Bien souvent, le développement SharePoint est perçu comme complexe car il est souvent difficile pour un néophyte de déployer ses jeux de test dans SharePoint.Il suffit donc de procéder de manière différente pour faciliter l’ensemble :

En premier lieu, vous assurez le déploiement en ne vous focalisant que sur la mise en ligne d’un composant élémentaire genre « Hello World ». Le tout bien sur dans une solution de développement VS.Net.



Ensuite, une fois le déploiement et sa solution de développement testée et validée, il ne vous reste plus qu’à vous focaliser sur la personnalisation du composant, soit le code pur et dur.

Tout simplement

3.2.1 Découverte du ONET.XML du modèle STS

Comme expliqué plus haut, le cœur du modèle de site se trouve dans le flux XML du ONET.XML (et de celui du modèle GLOBAL aussi). Nos modifications seront donc à faire dans ce fichier.

Observons de plus près le contenu du ONET.xml du modèle STS.Il contient 5 nœuds principaux constituant un site SharePoint :

Un « Site Definition » est donc constitué de :

NavBarsil permet de définir les barres de navigation du menu de lancement rapide de votre site comme celle des documents ou des listes par exemple

ListTemplate Cette section permet de définir le schema.xml des modèles de listes à utiliser dans ce modèle de site. Section un peu obsolète désormais car ces schémas sont externalisés par Microsoft sous forme de Feature

DocumentTemplates Cette section permet de définir les différents modèles de document par défaut des listes documentaire à utiliser dans ce modèle de site. Section un peu obsolète désormais car l’utilisation des Content Type permettent aussi les documents associés

Configuration Certainement, la section la plus importante. C’est ici que nous pouvons déclarer les diverses variantes d’utilisation d’un modèle de site. Toujours dans la volonté de granularité et de réutilisation des modèles, les configurations permettent d’utiliser un mix des diverses possibilités du Onet.xml.

Modules ce nœud contient les divers modules disponibles par les configurations d’un modèle de site. Les modules permettent de définir les différents fichiers physiques du site comme les pages ASPX ou les Master pages.

ServerEmailFooter Ce nœud définit simplement le contenu html du pied de page des alertes mails



Pour mieux comprendre la notion de configuration, nous pouvons prendre par exemple le contenu de la section du modèle de site STS. Une section de configuration permet de définir :

Les propriétés du site comme ses url de référence, sa description ou son icône Les listes du site à créer et leurs modèles associés La liste des références de modules à utiliser pour cette configuration Les identifiants de Feature de niveau Site Collection ou Site Web

Ainsi dans le cas du STS, il existe 3 configurations qui sont : le site d’équipe, le site documentaire et le site vierge. Comme ces 3 sites sont fonctionnellement similaires, Microsoft a préféré créer dans le modèle STS, 3 configurations où sont simplement définies leurs différences sans avoir à recréer tout l’ensemble.

Soit : Le site vierge ne contient aucune liste ni de WP sur sa page d’accueil Le site documentaire possède un accueil avec 3 zones de WebPart et une mise en avant des

documents Le site d’équipe a un accueil avec 2 zones de WebPart et des listes simples

Les modules sont liés intimement à la notion de customized/uncustomized ». C’est cette section qui pointe les fichiers système à virtualiser et mettre en cache lors de la génération de site. Chaque module permet donc à SharePoint de situer précisément le fichier à fournir au SPParser ainsi que l’adresse URL virtuelle après génération. Dans le cas d’une page à WebParts, on peut aussi déclarer les divers WebParts qui vont initialiser la page.

Comme la création d’un modèle de site se situera particulièrement au niveau de l’édition du fichier ONET.xml et le respect du schéma CAML, il est bon d’utiliser ce schéma dans VS.Net afin de faciliter l’opération.L’idéal est de l’automatiser en définissant le schéma SharePoint dans ceux par défaut de Visual Studio. Il s’agit du fichier WSS.xsd se trouvant dans 12/TEMPLATE/XML

Procédure Aller dans le répertoire [Installation de VS2005]\XML\Schemas Dupliquez le fichier catalog.xml en SPcatalog.xml Ouvrir dans un Notepad le fichier SPcatalog.xml Supprimer toutes les nœuds Associations & Schéma pour ne garde que la racine Coller le contenu suivant

<SchemaCatalog xmlns="http://schemas.microsoft.com/xsd/catalog"><Schema href="%CommonProgramFiles%/Microsoft Shared/web server extensions/12/TEMPLATE/XML/wss.xsd" targetNamespace="http://schemas.microsoft.com/sharepoint/"/>

</SchemaCatalog>

Désormais, il vous suffit de rajouter l’attribut xmlns dans le nœud racine de vos fichiers XML pour que VS.Net vous propose la liste des schémas disponibles



Et en sélectionnant le schéma http://schemas.microsoft.com/sharepoint, vous obtenez automatiquement le contrôle et l’IntelliSense du CAML de votre fichier

Schema Cachehttp://msdn2.microsoft.com/en-us/library/ms255821(VS.80).aspx

Pour reprendre l’exemple du modèle STS, celui ci contient 3 modules :

« Default » pointe le fichier default.aspx et le virtualise à la racine du site généré « DefaultBlank » pointe le fichier default.aspx et le virtualise à la racine du site généré « DWS » pointe le fichier defaultDWS.aspx et le virtualise à la racine du site généré sous le

nom default.aspx


http://msdn2.microsoft.com/en-us/library/ms255821(VS.80).aspx

http://schemas.microsoft.com/sharepoint

http://www.flickr.com/photos/andrewconnell/274840489/



Comme vous l’avez certainement remarqué, un module définit, avec l’attribut PATH, le chemin relatif au modèle de site contenant les fichiers et, avec l’attribut URL ,l’adresse finale après génération.Les sous nœuds FILE de MODULE définissent, par contre, chaque « upload virtuel » des fichiers ainsi que leur nom final. Ce qui explique le paramètre DWS et les 2 noms de Fichier du module DWS

<Module Name="DWS" Url=""> <File Url="defaultdws.aspx" Name="default.aspx">

… </File> </Module>

Le contenu des nœuds FILES représente les divers composants à injecter à la virtualisation de la page comme les WebParts de liste (ListViewWebPart) ou métiers.Comme le modèle de site vierge est vide, et bien l’élément FILE de son MODULE l’est aussi, tout simplement

L’appel de ces différents modules est fait tout simplement par une référence à leur nom dans les configurations des diverses variantes du modèle de site. A noter qu’une configuration peut appeler plusieurs modules tant qu’ils sont déclarés dans les nœuds MODULES du projet.

La partie configuration ne sera pas expliquée ici car nous allons simplement la personnaliser entièrement dans la suite du chapitre, et donc découvrir toutes les possibilités inhérentes du Site Définition

3.2.2 Personnalisation du nœud <Configuration/>

3.2.2.1 Nettoyons le surplus provenant de STS

Notre première opération consistera à ne garde que le stricte nécessaire pour créer notre modèle de site. Comme nous visons un simple site pour commencer, nous pouvons nous passer des diverses variantes du modèle d’équipe. Nous ne garderons que la configuration id=0 et le module Default.


Référence

Déclaration


A noter que si vous modifier le numéro de configuration par une autre valeur comme 141 par exemple, vous devez aussi modifier sa référence dans les fichiers WEBTEMP*.xml le déclarant

<Templates><Template Name="CoachSP" ID="14100">

<Configuration ID="141" …

3.2.2.2 Personnalisons le nœud des listes

Le nœud <LIST> permet de déclarer les listes à créer lors de la génération du site, voici, par exemple, la déclaration de la bibliothèque documentaire : Document Partagés

<List FeatureId="00BFEA71-E717-4E80-AA17-D0C71B360101" Type="101" Title="$Resources:core,shareddocuments_Title;" Url="$Resources:core,shareddocuments_Folder;" QuickLaunchUrl="$Resources:core,shareddocuments_Folder;/Forms/AllItems.aspx" />

La référence de Feature pointe vers un fragment XML contenant l’ensemble du schéma CAML définissant entièrement le modèle de liste documentaire, à la différence de SPS 2003. Après une rapide recherche plein texte dans « 12/TEMPLATE/FEATURE », le GUID « 00BFEA71-E717-4E80-AA17-D0C71B360101" représente le dossier DocumentLibrary. Voici un bon exemple de la granularité et la réutilisation du CAML dans SharePoint 2007

Il existe un « extension builder », dans le framework SharePoint, pour faciliter les gestions multilingues lors de la génération de site. En effet, quand vous utilisez la séquence suivante dans un flux CAML « Resources:core,shareddocuments_Title; », le moteur de génération va utiliser la clé shareddocuments_Title du fichier core.resx pour récupérer le libellé de texte à injecter

Afin de rendre notre modèle de site CoachSP multilingue, nous pouvons aussi rajouter nos propres libellés de traduction avec nos propres fichiers de ressources. Il suffit juste de créer des fichiers RESX dans le répertoire RESSOURCES de notre solution Visual Studio.Pour gérer différentes langues, il faut simplement rajouter en suffixe à nos fichiers RESX le code de langue (le code textuel et non le LCID) et donc de fournir un RESX par langue souhaité.Il est fortement conseillé de créer aussi un fichier RESX sans code de langue qui, lui, servira à la valeur par défaut si jamais un code de traduction n’existe pas dans la langue choisie lors de la génération

Soit dans notre exemple, CoachSiteDefinition.resx (ressource par défaut) CoachSiteDefinition.fr-FR.resx CoachSiteDefinition.en-US.resx



List of Locale ID (LCID) Values as Assigned by Microsoft http://www.microsoft.com/globaldev/reference/lcid-all.mspx

Language identifiers in the 2007 Office systemhttp://technet2.microsoft.com/Office/en-us/library/f5fee727-df49-4ef7-b073-dd6c08dfecfa1033.mspx?mfr=true

Reprenons notre exercice :

créer une nouvelle bibliothèque de document pour la gestion projet

Il suffit de rajouter un nœud LIST avec les références suivantes

Code XML pour une nouvelle liste documentaire<Lists> <List FeatureId="00BFEA71-E717-4E80-AA17-D0C71B360101" Type="101" Title="$Resources:CoachSiteDefinition,ProjectListTitle;" Url="$Resources:CoachSiteDefinition,ProjectListDescription;" QuickLaunchUrl="$Resources:core,shareddocuments_Folder;/Forms/AllItems.aspx" /> <List FeatureId="00BFEA71-E717-4E80-AA17-D0C71B360101" ………</Lists>

<List FeatureId="00BFEA71-D1CE-42de-9C63-A44004CE0104" Type="104" Title="$Resources:core,announceList;" Url="$Resources:core,lists_Folder;/$Resources:core,announce_Folder;">

<Data><Rows>

<Row><Field

Name="Title">$Resources:onetid11;</Field><Field

Name="Body">$Resources:onetid12;</Field><Field

Name="Expires"><ows:TodayISO/></Field></Row>

</Rows></Data>

</List>

Bien sur, les fichiers RESX CoachSiteDefinition en FR et US ont été mis à jour avec les clés et les valeurs déjà traduites

Ajouter une nouvelle spécifique à la liste d’annonce


http://technet2.microsoft.com/Office/en-us/library/f5fee727-df49-4ef7-b073-dd6c08dfecfa1033.mspx?mfr=true

http://technet2.microsoft.com/Office/en-us/library/f5fee727-df49-4ef7-b073-dd6c08dfecfa1033.mspx?mfr=true

http://www.microsoft.com/globaldev/reference/lcid-all.mspx




Les nœuds LIST peuvent contenir des nœuds DATA pouvant initialiser le contenu de votre liste. Dans le cas de la liste d’annonce, vous pouvez très bien rajouter des nœuds ou modifier ceux-ci pour placer votre propre annonce avec les libellés de traduction adéquats

Code XML <List FeatureId="00BFEA71-D1CE-42de-9C63-A44004CE0104" Type="104" Title="$Resources:core,announceList;" Url="$Resources:core,lists_Folder;/$Resources:core,announce_Folder;">

<Data><Rows>

<Row><Field Name="Title">$Resources:onetid11;</Field><Field Name="Body">$Resources:onetid12;</Field><Field Name="Expires"><ows:TodayISO/></Field>

</Row></Rows>

</Data></List>

3.2.3

3.2.3.1 Personnalisons le nœud Module

Dans cet exercice, nous allons répondre à un besoin récurrent de personnalisation des sites SharePoint en intégrant une master page et un modèle de page d’accueil spécifiques.

Ainsi, nous pourrons profiter du système de cache de ces pages, soit une facilité de mise à jour en travaillant directement sur ces fichiers et une garantie de performance. (Incompatible avec la notion customized obtenue depuis SharePoint Designer).

a. Créer les fichiers ASP.Net

Pour faciliter l’opération, nous allons simplement partir des fichiers originaux du modèle du site STS auquel nous rajouterons une légère modification. Evidemment, ce travail tient plus du métier d’un Web Designer mais ce n’est pas le but de ce tutoriel.

Soit le fichier Default.aspx que nous avions copié du répertoire STS. Nous rajouterons un simple bout de texte dans le placeholder principal

Code XML …<asp:Content ContentPlaceHolderID="PlaceHolderMain" runat="server"><h2>Custom Page</h2>…

3.2.4

Pour la Master Page, nous allons juste recopier le Default.master du modèle GLOBAL en CoachSP.master dans le dossier de notre « Site Definition » : CoachSP. Nous rajouterons un simple bout de texte dans le tableau principal avec un fond de couleur

Code XML …<td class='ms-bodyareaframe' valign="top" height="100%" style="background-color:#FCCC72"> <h1>Custom Master</h1>…



3.2.5

Bien sur, en mode projet, les modifications sont bien plus nombreuses que de simples ajouts de texte. Il peut s’agir d’intégrer une réelle charte graphique ainsi que des contrôles de navigation spécifique. La méthodologie reste la même sauf que pour rendre la tache plus aisée, il suffit de créer un site basé sur ce modèle simple puis de l’étendre à l’aide de SharePoint Designer. Une fois la Master Page et la page d’accueil conforme à vos attentes, vous pouvez recopiez leur code ASP.Net dans les fichiers de votre solution de développement et créer un autre site SharePoint pour valider la génération. SharePoint pouvant générer des millions de site, il n’y a pas de raison de vouloir se limiter à un seul pour travailler, donc il faut en profiter !

Pour des conceptions graphiques bien plus poussées et privilégiant la conception à base CSS, il est bien plus pratique de travailler à partir de Master Pages basiques ne contenant que les composants minimaux et nécessaires à SharePoint. Ainsi, un graphiste aura toute liberté de création avec la garantie d’une base de master fonctionnel.How to: Create a Minimal Master Pagehttp://msdn.microsoft.com/en-us/library/bb727372.aspx

b. Référencer ces fichiers comme nouveau modules

L’opération consiste juste à modifier la valeur des modules existant. Comme le fichier Default.aspx n’a pas changé de nom, son module est identique.


http://msdn.microsoft.com/en-us/library/bb727372.aspx



En ce qui concerne la Master Page, il faut lui en créer un nouveau pour permettre sa virtualisation dans la galerie des Master Page du site. La Master d’origine provenant du modèle GLOBAL, il suffit de s’inspirer de celui-ci, tout simplement :

Code XML …

<Modules><Module Name="Default" Url="" Path="">

<File Url="default.aspx" NavBarHome="True">…</File>

</Module><Module Name="MasterPageCoachSP"

List="116"Url="_catalogs/masterpage"RootWebOnly="FALSE">

<File Url="CoachSP.master" Type="GhostableInLibrary" IgnoreIfAlreadyExists="TRUE" />

</Module></Modules>…

3.2.6

Bien des secrets du langage CAML sont disponibles en parcourant tranquillement le contenu de l’ONET.xml du modèle GLOBAL. C’est ainsi que l’on peut comprendre comme pour cet exemple le fonctionnement des Master Page (en recherchant le mot « master ») :

Une galerie de master page :

<ListTemplate Name="mplib" DisplayName="$Resources:MasterPageGallery;" Description="$Resources:global_onet_mplib_desc;" SetupPath="global\lists\mplib" Type="116" BaseType="1" Path="GLOBAL" Hidden="TRUE" HiddenList="TRUE" NoCrawl="TRUE" Unique="TRUE" Catalog="TRUE" OnQuickLaunch="FALSE" SecurityBits="11" AllowDeletion="FALSE" AllowEveryoneViewItems="TRUE" Image="/_layouts/images/itdl.gif" AlwaysIncludeContent="TRUE" DocumentTemplate="100" />

Un module pour la default.master

<Module Name="DefaultMasterPage" List="116" Url="_catalogs/masterpage" RootWebOnly="FALSE"> <File Url="default.master" Type="GhostableInLibrary" IgnoreIfAlreadyExists="TRUE" /> </Module>

La référence au fichier Master pour paramétrer le site

<Configuration ID="0" Name="Default" MasterUrl="_catalogs/masterpage/default.master">



Le Global permet aussi de comprendre et d’identifier les divers références de type dans les bibliothèques SharePoint. Le nœud ListTemplate ainsi que les GUID de Feature nous les indique clairement :

Galerie des Master Page : 116 Galerie des utilisateurs : 112 Galerie des modèles utilisateurs de site : 111 Galerie des WebParts : 113 Galerie des modèles utilisateurs de liste : 114

c. Référencer les modules

Il faut préciser la configuration des modules à utiliser, soit celui de la page default.aspx et celui de la nouvelle Master Page

Code XML …

<Configuration ID="141" Name="Default" MasterUrl="_catalogs/masterpage/CoachSP.master" >

<Lists>…</Lists><Modules>

<Module Name="Default" /><Module Name="MasterPageCoachSP" />

</Modules>

d. Déclarer la Master Page par défaut du site à générer

Toujours en suivant l’exemple du modèle GLOBAL, il faut renseigner l’attribut MasterUrl du nœud Configuration avec l’adresse virtuel de la nouvelle Master Page.Soit [URL de la galerie de la Master Page]/[URL du module de la Master Page] = "_catalogs/masterpage/CoachSP.master"

Code XML …

<Configuration ID="141" Name="Default" MasterUrl="_catalogs/masterpage/CoachSP.master" >

<Lists>…</Lists><Modules>

<Module Name="Default" /><Module Name="MasterPageCoachSP" />

</Modules>

3.2.6.1 Personnalisons le nœud File de Module

Désormais, notre modèle de site SharePoint possède sa propre Master Page ainsi que ses propres listes. Nous pouvons aussi modifier le paramétrage des WebParts de sa page d’accueil.

Depuis SharePoint 2007, les WebParts ne sont plus une spécificité de cette plateforme. Elles proviennent réellement du framework Portal d’ASP.Net 2.0. Une WebPart dans SharePoint est donc la combinaison d’un classe métier basée sur System.Web.UI.WebControls.WebParts ainsi qu’un manifeste XML, les fichiers *.webpart déclarant l’instance et les propriétés publiques de cette classe.



Ainsi, le moteur ASP.Net peut dynamiquement charger de nouvelles WebParts dans une page en procédant à une instance de la dll via sa référence de manifeste.

ASP.NET 2.0: Personalize Your Portal with User Controls and Custom Web Partshttp://msdn.microsoft.com/en-us/magazine/cc300767.aspx

Continuons l’exercice : ajouter/modifier les WebParts de la page d’accueil

Ce paramétrage concerne les sous nœuds de MODULE/FILE dans votre fichier ONET.XML.

Si nous reprenons le fichier actuel, nous pouvons découvrir la configuration de divers WebParts comme :

Une vue sur la liste d’annonces :

<View List="$Resources:core,lists_Folder;/$Resources:core,announce_Folder;" BaseViewID="0" WebPartZoneID="Left" />

Une vue sur la liste de calendrier :

<View List="$Resources:core,lists_Folder;/$Resources:core,calendar_Folder;" BaseViewID="0" RecurrenceRowset="TRUE" WebPartZoneID="Left" WebPartOrder="2" />

Une WebPart d’image sur le logo Microsoft

<AllUsersWebPart WebPartZoneID="Right" WebPartOrder="1"><![CDATA[ <WebPart xmlns="http://schemas.microsoft.com/WebPart/v2" xmlns:iwp="http://schemas.microsoft.com/WebPart/v2/Image"> <Assembly>Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c</Assembly> <TypeName>Microsoft.SharePoint.WebPartPages.ImageWebPart</TypeName> <FrameType>None</FrameType> <Title>$Resources:wp_SiteImage;</Title> <iwp:ImageLink>/_layouts/images/homepage.gif</iwp:ImageLink> <iwp:AlternativeText>$Resources:core,sitelogo_wss;</iwp:AlternativeText> </WebPart> ]]></AllUsersWebPart>

Une vue sur la liste des liens

<View List="$Resources:core,lists_Folder;/$Resources:core,links_Folder;" BaseViewID="0" WebPartZoneID="Right" WebPartOrder="2" />

Comme vous pouvez le constater, pour ajouter une WebPart de liste, il faut utiliser le nœud VIEW avec, en attribut, l’adresse de génération de cette liste et l’identifiant de la vue à afficher.

En ce qui concerne les WebParts, il faut préciser toute son instance en XML via le nœud AllUsersWebPart.

L’instance XML des WebPart correspond justement à son manifeste XML !


http://msdn.microsoft.com/en-us/magazine/cc300767.aspx



En prenant un site existant en mode édition de page, il vous suffit d’exporter une WebPart (donc sa configuration et non sa DLL, il ne faut pas confondre) et de recopier le contenu du manifeste dans le nœud

Pour notre exercice, nous effectuerons 2 actions :

Modifier l’image d’accueil

Code XML …

<Module Name="Default" Url="" Path=""><File Url="default.aspx" NavBarHome="True">

<View List="$Resources:core,lists_Folder;/$Resources:core,announce_Folder;" BaseViewID="0" WebPartZoneID="Left" />

<View List="$Resources:core,lists_Folder;/$Resources:core,calendar_Folder;" BaseViewID="0" RecurrenceRowset="TRUE" WebPartZoneID="Left" WebPartOrder="2" />

<AllUsersWebPart WebPartZoneID="Right" WebPartOrder="1">

<![CDATA[ <WebPart xmlns="http://schemas.microsoft.com/WebPart/v2" xmlns:iwp="http://schemas.microsoft.com/WebPart/v2/Image"> <Assembly>Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c</Assembly> <TypeName>Microsoft.SharePoint.WebPartPages.ImageWebPart</TypeName> <FrameType>None</FrameType> <Title>$Resources:wp_SiteImage;</Title> <iwp:ImageLink>$Resources:CoachSiteDefinition,ImageSite;</iwp:ImageLink> <iwp:AlternativeText>$Resources:core,sitelogo_wss;</iwp:AlternativeText> </WebPart> ]]>

</AllUsersWebPart>…

La WebPart Image correspond à la classe Microsoft.SharePoint.WebPartPages.ImageWebPart de l’assemblée Microsoft.SharePoint.dllPour modifier l’adresse de sa propriété image, il faut juste modifier le paramètre :



<iwp:ImageLink>$Resources:CoachSiteDefinition,ImageSite;</iwp:ImageLink>

Dans notre exemple, afin de faciliter la maintenance du modèle, l’URL de l’image n’est pas précisée directement dans le flux XML mais est externalisée dans le fichier de ressource CoachSiteDefinition.resx. Après tout, c’est bien le rôle des fichiers de ressource de centraliser les ressources, non ?

Ajouter un texte d’accueil

Code XML …<Module Name="Default" Url="" Path=""> <File Url="default.aspx" NavBarHome="True"> <View List="$Resources:core,lists_Folder;/$Resources:core,announce_Folder;" BaseViewID="0" WebPartZoneID="Left" /> <View List="$Resources:core,lists_Folder;/$Resources:core,calendar_Folder;" BaseViewID="0" RecurrenceRowset="TRUE" WebPartZoneID="Left" WebPartOrder="2" /> <AllUsersWebPart WebPartZoneID="Right" WebPartOrder="1">…</AllUsersWebPart> <AllUsersWebPart WebPartZoneID="Top" WebPartOrder="1">

<![CDATA[ <?xml version="1.0" encoding="utf-8"?><WebPart xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/WebPart/v2"> <Title>Introduction</Title> <FrameType>None</FrameType> <Description>Use for formatted text, tables, and images.</Description> <IsIncluded>true</IsIncluded> <ZoneID>Left</ZoneID> <PartOrder>0</PartOrder> <FrameState>Normal</FrameState> <AllowRemove>true</AllowRemove> <AllowZoneChange>true</AllowZoneChange> <AllowMinimize>true</AllowMinimize> <AllowConnect>true</AllowConnect> <AllowEdit>true</AllowEdit> <AllowHide>true</AllowHide> <IsVisible>true</IsVisible> <HelpMode>Modeless</HelpMode> <Dir>Default</Dir> <MissingAssembly>Cannot import this Web Part.</MissingAssembly> <PartImageLarge>/_layouts/images/mscontl.gif</PartImageLarge> <Assembly>Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c</Assembly>



<TypeName>Microsoft.SharePoint.WebPartPages.ContentEditorWebPart</TypeName> <ContentLink xmlns="http://schemas.microsoft.com/WebPart/v2/ContentEditor" /> <Content xmlns="http://schemas.microsoft.com/WebPart/v2/ContentEditor">

$Resources:CoachSiteDefinition,ContentWebPart; </Content>

<PartStorage xmlns="http://schemas.microsoft.com/WebPart/v2/ContentEditor" />

</WebPart>]]>

</AllUsersWebPart>

3.2.7…

Même principe que pour l’image, nous avons simplement utilisé une WebPart Editeur de contenu sur un site existant, préciser un petit message puis nous avons exporté le paramétrage pour le reprendre dans le fichier ONET.XML

La WebPart éditeur de contenu (ou CEWP pour les habitués) se base sur la classe .SharePoint.WebPartPages.ContentEditorWebPart de l’assemblée Microsoft.SharePoint.dll

Toujours dans la continuité, le texte inséré a été externalisé dans le fichier de ressource et traduit aussi bien en anglais qu’en français. Sans cela, avec un texte en dur dans le manifeste, le site n’aurait pu être généré dans différentes langues, la WebPart d’accueil serait toujours restée dans sa version originale…

Attention, comme le manifeste XML doit être inséré dans un flux XML, il doit être encapsulé entre des balises <![CDATA[ … ]]> afin de le préciser comme non interprétable par le moteur de génération SharePoint.Cependant, si vous voulez insérer du texte riche dans cette WebPart, vous devez déclarez aussi de l’HTML dans ce manifeste et malheureusement, il n’est pas possible d’enchainer les balises <![CDATA[ … ]]> selon la norme XML.Ainsi, pour répondre à cette problématique, le code HTML à été ré encodé en HTML et stocké ensuite dans les fichiers de ressources pour éviter la présence des balises HTML

En pratique, les <> on été remplacés par &lt ; &gt ;

Exemple :"<FONT size=5><EM>Welcome on this customized website</EM></FONT>" est devenu

<FONT size=5><EM>Welcome on this customized website</EM></FONT>

Si jamais vous passez par l’interface de saisie des RESX de Visual Studio, vous pouvez collez le code HTML sans le reprendre. Il y a un ré encodage automatique des balises !



3.2.7.1 WebFeature et SiteFeature

Voici certainement 2 des nœuds les plus importants dans la conception de modèle de site SharePoint.

SiteFeatures décrit les différentes Features automatiquement activées à la création du site s’il est en racine d’une nouvelle collection. Dans le cas du modèle STS, vous pouvez découvrir 2 Features très importantes. La première met en place la suite des WebParts de base comme la WP éditeur de contenu ou d’image. La seconde gère le déploiement du modèle de workflow à 3 états.

WebFeatures décrit les différentes Feature à activer pour le site à sa création, qu’il soit en racine ou en sous niveau. Ici, on obtient les références vers les Feature d’accès à la version mobile du site ainsi que la déclaration de l’ensemble des types et modèles propre au site collaboratif

Les Features sont omniprésentes dans le développement SharePoint, la plupart des éléments se déploient justement par l’intermédiaire de celles-ci.

Ce thème ne peut être couvert dans un seul chapitre, c’est pourquoi, le prochain tutoriel lui sera exclusivement dédié. La suite n’en sera que plus intéressante.

3.2.8 Tester & déployer votre modèle de site

Maintenant, votre site est prêt à être testé et évalué. Il peut gérer un aspect multilingue, une mise en page spécifique, un contenu propre ainsi qu’une charte graphique particulière.

Il n’est pas forcément bon de procéder à l’ensemble de ces modifications en une fois, sauf si bien sur vos samples de code sont dignes de fois. Bien souvent, les développeurs SharePoint préfèrent procéder par itération, en validant étape par étape.

En effet, le moteur de génération basé sur le CAML de SharePoint est certainement un des moins verbeux en cas d’erreur : il vous précisera juste que le modèle a généré une erreur …



D’où l’importance de valider et documenter chaque étape de modification de votre modèle de site plutôt que de partir rapidement à tout modifier dans le ONET.xml sans faire de sauvegarde intermédiaire.

Un archivage régulier avec un outil comme SourceSafe est vraiment un plus ! (D’où l’intérêt réel de concevoir depuis Visual Studio).

Cependant, la seule manière de tester réellement la validité de votre site SharePoint, reviens naturellement à le générer une fois sur une collection de sites dédié comme site de racine. Ainsi vous évitez les effets de bords ou les configurations hasardeuses d’une collection de sites déjà existante.

Toujours dans un esprit de productivité, il suffit d’automatiser le processus en utilisant l’outil de ligne de commande de SharePoint : STSADM. En effet, il est très aisé de scripter la création./suppression d’une collection de site via cet outil.

%STSADM% -o deletesite pour supprimer une collection de site %STSADM% -o createsite pour créer la collection de site

Nous modifierons donc le script d’installation de notre solution Visual Studio pour déployer, supprimer et créer une collection de sites de test basée sur notre modèle personnalisé.

Code XML cd ..@echo off

3.2.9ECHO "-- FULL Deploy of the solution --"@SET STSADM="C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\stsadm.exe"@SET SPDIR="C:\program files\common files\microsoft shared\web server extensions\12"@SET SITEURL=http://O12SRV:141/sites/coach_site@SET TEMPLATE=CoachSP#141

3.2.10xcopy 12\TEMPLATE %SPDIR%\TEMPLATE /s /yxcopy 12\RESOURCES %SPDIR%\RESOURCES /s /y

3.2.11IISRESET

3.2.12ECHO "Delete the site"%STSADM% -o deletesite -url %SITEURL%

3.2.13ECHO "Create the site"%STSADM% -o createsite -url %SITEURL% -ownerlogin "O12SRV\Administrator" -owneremail "[email protected]" -sitetemplate %TEMPLATE% -title "CoachSP" -description "Site du coach SP"



3.2.14Pause

Pour héberger nos collections de sites, nous nous appuyons sur l’adresse générique « /SITES » de toute Web Application SharePoint.

Après avoir lancé le fichier de script, vous pouvez admirez votre modèle de site personnalisé et le tester autant de fois qu’il est nécessaire sans perdre trop de temps à cause du IISRESET ou des interfaces d’administration de SharePoint

Soit en affichage

Note :


MasterPage spécifique

Page spécifiqueWebPart de contenu

WebPart Image

Liste de document projet


4 Pour aller plus loin…Ce tutoriel a eu pour vocation de vous évangéliser sur la conception de modèle de site ou « Site Definition SharePoint. La conception est basée exclusivement sur l’approche déclarative du CAML ce qui permet d’effectuer rapidement des fonctions de génération très avancées. Il faut cependant avoir une vue assez large du schéma pour pouvoir profiter pleinement de son potentiel avant de prendre une option orientée langage de développement. Les API SharePoint permettent effectivement de combler tout manque au modèle déclaratif.

Il existe ainsi de nombreuses options qu’il n’a pas été possible de couvrir dans ce tutoriel mais qui a elles seules enrichissent grandement l’aspect fonctionnel de vos sites tel que le nœud <ExecuteUrl Url="… " /> dans <Configuration> . Il permet de préciser une URL de démarrage au premier lancement de votre site, comme une page de configuration par exemple.

Une bonne astuce serait de l’utiliser sur l’adresse « _layouts/themeweb.aspx » qui vous permet de modifier le thème graphique de votre site

Mais pour continuer plus en avant dans la personnalisation de votre modèle de site, en dehors, bien sur de problématiques plus orientées ASP.Net tels que les contrôles de navigation, les mises en page ou les Master Pages, il est fondamental de profiter du principe des Features.

En effet, le Site Definition constitue la colonne vertébrale de votre site mais son extensibilité, sa maintenance et son évolution n’en sera que facilité si la majorité de ces composants peut être externalisée dans des Features.

Vous profiterez ainsi de leurs cycles de vie, de leurs autonomies ainsi que bien d’autres options que nous couvrirons dans le prochain tutoriel.

Rappelez-vous qu’un bon modèle de site se juge surtout plus par ses nombreuses Features que par la complexité de son propre code CAML : plus le modèle est simple, plus il est simple de le maintenir et le faire évoluer



5 Rendez-vous dans le prochain atelier…Dans l’atelier 3, « créer votre Feature déclarative pour SharePoint », vous allez mettre en place une solution complète sous Visual Studio d’une Feature SharePoint entièrement en CAML. Les Features sont au cœur même de l’extensibilité du système. Ce prochain tutoriel tachera de vous les présenter via une suite d’exemple à la technicité croissante.

Lexique

Truc et astuce

Zoom sur la technique

Définition d’un concept avancé

Référence MSDN

Attention sécurité



download.microsoft.comdownload.microsoft.com/.../2009/CoachSPDevAtelier02.docx · Web viewCes...

Documents

Transcript of download.microsoft.comdownload.microsoft.com/.../2009/CoachSPDevAtelier02.docx · Web viewCes...