Découvrez les importantes améliorations de SharePoint Services 3.0 destinées aux développeurs
Par Ted Pattison
Consultez cet article en anglais
Cet article est basé sur une version préliminaire de Windows SharePoint Services. Toutes les informations qu'il contient peuvent être sujettes à modification.
Sur cette page
Cet article utilise les technologies suivantes :
WSS, Windows Server 2003
Le lancement de la prochaine version de Microsoft Office SharePoint Server (MOSS), qui inclut Windows® SharePoint® Services (WSS) version 3.O, approche à grands pas. A l'instar des versions précédentes, WSS propose des solutions intégrées en terme de collaboration qui facilite la réalisation par les utilisateurs de création et conception de sites internet avec des éléments partagés comme des calendriers, des listes de contacts et des librairies de documents. Mais WSS est bien plus qu'un outil de collaboration pour les utilisateurs finaux. Il s'agit d'une plate-forme de développement complète qui apporte une grande valeur ajoutée à ASP.NET.
WSS 3.0 est un logiciel compagnon pour Windows Server™ 2003. Parmi ses principales fonctionnalités, WSS est un moteur évolutif de mise en service de sites, qui facilite également la création et la gestion de centaines ou des milliers de sites internet tout en les rendant accessibles à des dizaines de milliers d'utilisateurs. WSS doit son évolutivité à une architecture conçue sur un modèle d'environnement de ferme de serveurs Internet. Cette architecture est basée sur des serveurs Internet frontaux sans état qui s'appuient sur SQL Server™ pour stocker le contenu et les autres données liées au site.
La valeur ajoutée qu'apporte WSS à la plate-forme de développement ASP.NET 2.0 doit son origine à son modèle extensible, qui facilite la mise en service et le stockage des pages, des listes et des librairies de documents. La mise en service peut être conduite soit par un code personnalisé, soit par des actions d'utilisateurs dans l'interface utilisateur via un navigateur. Dans les coulisses, WSS détermine automatiquement où et comment stocker les données et fournit les éléments de l'interface utilisateurs qui permet aux utilisateurs d'ajouter, de voir et de modifier du contenu.
Je vais me concentrer sur la principale amélioration à destination des développeurs que propose la version 3, ainsi que sur les modifications de terminologie qui l'accompagnent. Pour plus d'informations, reportez-vous à l'article "SharePoint: Use Windows SharePoint Services as a Platform for Building Collaborative Applications" paru dans le numéro de juillet 2004 de MSDN®Magazine.
Veuillez garder à l'esprit que les recherches et les codes présentés dans le présent article sont basés sur la version Bêta 1 de WSS. Il est possible que certains des termes et codes soient modifiés dans la version finale.
Intégration avec ASP.NET 2.0
La mise en service de WSS 3.0 débute par un site Web IIS. Avant de créer votre premier site WSS, vous devez lancer une procédure administrative pour étendre la fonctionnalité WSS à un ou plusieurs site(s) Web IIS. Sous WSS 2.0, le terme "serveur virtuel" décrivait un site Web IIS étendu avec la fonctionnalité SharePoint. Pour éviter toute confusion avec un autre produit Microsoft possédant le même nom, la documentation de WSS 3.0 réfère désormais à un site Web IIS étendu avec la fonctionnalité WSS comme une Application Web.
WSS 2.0 était intégré à l'IIS 6.0 et à ASP.NET 1.1 en utilisant une DLL de filtre ISAPI, qui provoquait des requêtes de routage IIS adressées au WSS avant l'ASP.NET. Ce routage pouvait poser certains problèmes car le WSS prenait le contrôle d'une requête HTTP avant qu'elle ait pu être initialisée de façon appropriée dans un contexte ASP.NET.
L'intégration WSS avec ASP.NET a cependant été complètement reconçue pour sa version 3. Tout d'abord, WSS 3.0 est construit sur ASP.NET 2.0, qui apporte des améliorations significatives par rapport à ASP.NET 1.1. De plus, l'infrastructure de routage a été améliorée en ôtant le filtre ISAPI et en ajoutant un HttpModule ainsi qu'un HttpHandler qui sont enregistrés auprès d'ASP.NET en utilisant des entrées Web.config standards. Cela signifie que les requêtes HTTP entrantes sont systématiquement traitées par l'environnement d'exécution d'ASP.NET et sont entièrement initialisées dans le contexte ASP.NET avant d'être transférées vers le code responsable du traitement spécifique à WSS.
Lorsque vous étendez un site Web IIS afin qu'il devienne une Application Web, WSS 3.0 ajoute un mappage d'application générique à la métabase IIS. Ce mappage route toutes les requêtes HTTP entrantes vers l'exécution ASP.NET, sans tenir compte du type de fichier (.pdf, .doc, .docx, etc.). ASP.NET transfère ensuite la requête au WSS pour traitement.
La nouvelle architecture gère également les défauts liés à la façon dont les pages .aspx sont analysées et compilées. L'analyseur de pages .aspx utilisé par ASP.NET 1.1 fonctionne uniquement avec les pages situées dans le système local. L'architecture WSS s'appuie en revanche sur le stockage des pages .aspx dans une base de données du serveur SQL Server, c'est pourquoi il ne pourrait pas faire appel à l'analyseur de page d'ASP.NET 1.1. Et malheureusement, l'analyseur SharePoint développé pour le remplacé ne propose pas certains des fonctions sympas qu'offrait l'analyseur de page d'ASP.NET.
En revanche, ASP.NET 2.0 inclut une nouveauté, un type de composant enfichable nommé fournisseur de chemin d'accès virtuel. Le but de cette fonction est d'offrir aux développeur la capacité d'écrire un composant personnalisé qui récupère les pages .aspx pages (ou tout autre contenu traité par ASP.NET) à partir de n'importe quel emplacement, même dans une base de données comme SQL Server. Une fois que le fournisseur de chemin d'accès virtuel récupère une page .aspx, il peut ensuite la faire analyser et compiler par ASP.NET. Un autre composant, PageParserFilter, permet à SharePoint de contrôler la manière dont les pages sont analysées et compilées ainsi que le contenu qui est exécuté sur ces pages.
WSS 3.0 inclut son propre chemin d'accès virtuel, appelé SPVirtualPathProvider, comme indiqué dans l'Illustration 1. Comme vous pouvez le voir, SPVirtualPathProvider possède la capacité de récupérer des pages .aspx à partir de SQL Server puis de les transférer à l'analyseur .aspx fourni par ASP.NET 2.0. En conséquence, WSS 3.0 ne souffre pas de la même limitation de fonctions que la version précédente de WSS concernant l'analyse de pages.
Illustration 1. Fournisseur de chemin d'accès virtuel personnalisé et ASP.NET 2.0
Modèles de pages
Les termes "ghosting" (mise en mémoire cache) et "unghosting" (copie de pages) sont souvent utilisés en conjonction avec les pages .aspx d'un site WSS 2.0. Le ghosting permet à un serveur Web frontal de stocker un modèle de page .aspx sur son système local et de le partager avec plusieurs sites différents. Cette méthode améliore la performance, car le WSS peut alimenter des milliers de sites en utilisant un modèle de page stocké sur le système local du serveur et chargé une seule fois dans la mémoire de ce dernier.
WSS 2.0 prenait en charge les modifications faites par les utilisateurs au modèle de page grâce à des outils tels que Microsoft® Office FrontPage® 2003. Lorsqu'un utilisateur modifie un modèle de page et enregistre les modifications, une version personnalisée de la page est stockée dans SQL Server pour ce site particulier. Cette opération est souvent appelée unghosting.
WSS 3.0 prend toujours en charge les modèles de pages présentes sur le serveur internet, tout comme les versions personnalisées qui sont stockées sur le serveur SQL Server. Cependant, la documentation n'utilisent plus les termes "ghosting" et "unghosting". Désormais, le terme "page non personnalisée" décrit un modèle de page utilisé directement à partir du système local du serveur internet, alors que "page personnalisée" est utilisé en référence à une version modifiée du modèle de page qui a été inscrite dans la base de données du contenu d'un site en particulier.
Microsoft Office FrontPage 2003 a été renommé Office SharePoint Designer 2007, mais le public ciblé reste les utilisateurs plutôt que le développeurs. Ce logiciel reste néanmoins un bon outil pour les développeurs WSS. SharePoint Designer propose à la fois un éditeur de code et un outil de conception "tel écrit, tel écran" permettant de personnaliser des pages .aspx et .master à l'intérieur de sites WSS. Vous pouvez également créer de nouvelles pages au sein d'un site sans qu'elles ne correspondent au modèle de page présent sur le serveur Web. Vous avez aussi la possibilité de créer des listes et des librairies de documents, et il existe même un nouvel assistant à la création de flux de travail personnalisés dans un site WSS. (J'y reviendrai plus en détails plus tard.)
Travail avec des Pages maîtres
L'un des aspects les plus fastidieux de la personnalisation des sites avec WSS 2.0 était la création d'une apparence harmonisée dans l'ensemble des pages, car ASP.NET 1.1 ne proposait pas de techniques adaptées de création de modèles de pages. En conséquence, beaucoup de développeurs se résolvaient à copier les mises en page HTML et à les coller de page en page. Comme vous pouvez l'imaginer, cela rendait très difficile la maintenance d'un site dont les besoins en terme de mise en page différaient du site WSS standard.
Une solution a été trouvée à ce problème grâce au lancement d'une fonction puissante de création de modèles de pages appelé Pages maîtres et associé à ASP.NET 2.0. Une Page maître est un modèle qui permet de déterminer la mise en page d'une page standard pour un site complet, comprenant des éléments comme une bannière, des boutons de navigation et d'autres menus. Les pages liées à la Page maître sont appelées pages de contenu.
Le principe de base est que chaque page de contenu est liée à la Page maître, dont elle récupère la mise en page partagée avant d'insérer son contenu personnalisé dans les espaces réservés désignés. Pour plus d'informations sur le fonctionnement des Pages maîtres sous ASP.NET, consultez l'article de Fritz Onion intitulé "Master Pages: Master Your Site Design with Visual Inheritance and Page Templates" dans le numéro de juin 2004 de MSDN Magazine (en anglais).
WSS 3.0 a été conçu dès le départ pour inclure l'infrastructure de Page maître d'ASP.NET 2.0. Avec la version 3, chaque site a accès à un catalogue spécial appelé Galerie de Page maître qui contient une page intitulée default.master. Cette page définit la mise en page commune pour la page d'accueil de chaque site (default.aspx), ainsi que toutes les pages de formulaire WSS standard associées aux listes et librairies de documents (AllItems.aspx et NewItem.aspx, par exemple). La mise en page de la Page maître inclut des menus et boutons de navigation standard. L'Illustration 2 présente un exemple de page basée sur la mise en page standard définie par default.master.
Illustration 2 Mise en page standard définie par default.master
Les éléments définis par default.master incluent un certain nombre d'espaces réservés comme PlaceHolderPageTitle, PlaceHolderMain, et PlaceHolderLeftNavigation, ce qui facilite la création d'une nouvelle page de contenu personnalisée possédant la même mise en page des autres pages d'un site donné. Observez la simplicité de la définition d'une page de contenu :
<%@ Page="" language="VB" MasterPageFile="~masterurl/
default.master" %>
<asp:Content ContentPlaceHolderId="PlaceHolderMain"
runat="server">
<h3>Welcome to customization with Windows SharePoint Services 3</h3>
This is so much easier than it was in version 2!
</asp:Content>
Elle se borne à placer un fragment minime de contenu HTML dans PlaceHolderMain, tout en produisant la mise en page typique du site, avec ses icônes, ses menus et ses barres de navigations, comme indiqué par l'Illustration 3. Une fois que vous avez appris à utiliser l'ensemble des espaces réservés définis dans la page default.master, vous pouvez facilement remplacer des éléments WSS comme des menus ou barres de navigations avec vos propres boutons ASP.NET. Ces modifications peuvent être apportées à un site entier, ou à une collection de sites.
Illustration 3 Personnalisation d'une page de contenu à partir de la Page maître
Les Pages maîtres et les pages de contenu sont stockées et chargées comme les modèles de pages et les pages personnalisées dont nous parlions plus haut. Il existe des modèles de pages définis pour la Page maître, tout comme pour les pages de contenus, qui sont stockées sur le système local du serveur Web frontal. Chaque site utilise au départ des versions non personnalisées (ghosted) du modèle de la Page maître et des modèles de page de contenu. Lorsqu'un utilisateur personnalise et sauvegarde l'une de ces pages pour un site particulier en utilisant un outil tel que SharePoint Designer, une version personnalisée (unghosted) est sauvegardée dans la base de données du serveur SQL Server.
Si vous le désirez, vous pouvez personnaliser la Page maître pour un site, en laissant les pages de contenu non personnalisées. A l'inverse, vous pouvez personnaliser une ou plusieurs pages de contenu sans pour autant modifier la Page maître. Autre nouveauté, vous pouvez annuler toutes les modifications apportées : WSS et SharePoint Designer proposent des commandes de menu simples pour annuler les modification de personnalisation de la base de données du SQL Server pour revenir au modèle de page original.
Comme vous l'avez certainement remarqué, la page de contenu que nous avons vu plus haut est liée à la Page maître par une syntaxe spéciale, sous la forme de ~masterurl/default.master. Il s'agit d'une référence marquée à une Page maître qui peut être modifiée par un programme sur l'ensemble du site. Pour ce faire, vous obtenir une référence SPWeb au site actuel, puis mettre à jour les propriétés MasterUrl (voir Illustration 4).
Veuillez noter que chaque site dispose de sa propre Galerie de Page maître avec un default.master, ainsi que ses propres propriétés MasterUrl. Cela signifie que les sites faisant partie d'une collection de sites n'utilisent pas automatiquement la même Page maître. Il est cependant facile, à l'aide d'une fonction récursive, d'écrire un code dans le modèle de l'objet WSS 3.0 pour synchroniser un site de niveau supérieur and tous les sites enfants dans une collection de sites pour qu'ils utilisent tous la même Page maître, comme montré dans l'Illustration 5.
Un autre marqueur pour les Pages maîtres prend la forme de ~masterurl/custom.master. Ce marqueur dynamique fonctionne en coordination avec la propriété CustomMasterUrl d'un site et fournit une cible Page maître secondaire qui peut être redirigée par un programme. Il existe également deux marqueurs statiques de Page maître qui débutent soit par ~site, soit par ~sitecollection. Ces marqueurs statiques permettent d'encoder en dur un chemin d'accès relatif vers une Page maître soit à partir de la racine du site actuel, soit à partir de la racine de la collection de sites actuelle.
Les composants WebPart dans WSS
L'une des manières préférées des développeurs pour étendre des sites WSS 2.0 était de créer des WebParts personnalisées. Les WebParts constituent un outil sympa, parce qu'ils ajoutent des dimensions supplémentaires à la personnalisation par l'utilisateur. Etant donné la popularité remportée par les Web Parts dans WSS 2.0, Microsoft a décidé d'ajouter un support pour une nouvelle infrastructure WebPart pour ASP.NET 2.0 qui est similaire à l'infrastructure WebPart de WSS, même si elle possède des différences.
En conséquence, il existe désormais deux styles différents de WebPart. Les anciennes WebParts de style WSS dépendent de la Microsoft.SharePoint.dll et doivent hériter de la classe de base WebPart dans l'espace de noms Microsoft.SharePoint.WebPartPages. Les anciennes WebParts de style ASP.NET dépendent du fichier System.Web.dll et doivent hériter d'une autre classe de base WebPart dans l'espace de noms System.Web.UI.WebControls.WebParts.
WSS 3.0 avait un but de conception important : que les WebParts de style WSS et ceux de style ASP.NET soient tous deux pris en charge. Microsoft a pu atteindre ce but en basant la fonctionnalité de prise en charge des composants WebPart de WSS 3.0 sur l'infrastructure WebPart ASP.NET, puis en modifiant le fichier Microsoft.SharePoint.dll de manière à ce que les composants WebPart de style WSS conçus pour l'environnement WSS 2.0 soient compatibles avec l'environnement 3.0.
Pour exécuter des composants WebPart dans une application ASP.NET 2.0, vous devez créer une page .aspx qui contient exactement une instance du contrôle WebPartManager et un ou plusieurs contrôles WebPartZone. Le contrôle WebPartManager est responsable de la sérialisation des données relatives aux composants WebPart, ainsi que du stockage et de la récupération de ces données à partir des tables de la base de données des services ASP.NET.
La page .aspx faisant office de page WebPart peut contenir des composants EditorPart permettant aux utilisateurs de personnaliser les propriétés WebPart persistantes. Les pages WebPart peuvent par ailleurs renfermer des composants CatalogPart qui offrent aux utilisateurs la possibilité d'ajouter de nouveaux composants WebPart dans les différentes zones. WSS 3.0 ajoute les composants EditorPart et CatalogPart à votre place, ce qui évite à un concepteur de pages Web d'avoir à le faire explicitement. (Pour plus d'informations sur le fonctionnement de l'infrastructure WebPart ASP.NET 2.0, consultez l'article « ASP.NET 2.0 : Personnalisez votre portail grâce aux contrôles utilisateur et aux composants WebPart personnalisés ».)
L'infrastructure WebPart WSS 3.0 est fondée sur un contrôle appelé SPWebPartManager qui est issu du contrôle WebPartManager ASP.NET 2.0. SPWebPartManager remplace le comportement standard du contrôle WebPartManager de manière à rendre les données WebPart persistantes dans la base de données de contenu WSS (au lieu de la base de données de services ASP.NET). Dans la plupart des cas, vous n'avez pas à vous inquiéter du contrôle SPWebPartManager car la seule instance requise est déjà définie dans default.master. Lorsque vous créez une page de contenu liée à default.master, le contrôle SPWebPartManager est déjà présent.
Les autres contrôles apparaissant sur une page WebPart WSS 3.0 standard sont indiqués à la figure 6. Veuillez noter que les zones WebPart des pages WebPart WSS 3.0 doivent être créées au moyen du contrôle WebPartZone défini dans l'espace de noms Microsoft.SharePoint.WebPartPages, et non au moyen du contrôle WebPartZone standard d'ASP.NET 2.0.
Figure 6 : Contrôles d'une page WebPart
Les instances du contrôle WebPartZone sont habituellement définies dans les pages de contenu. La figure 7="" montre un exemple simple de création d'une page de contenu conçue pour faire office de page WebPart sur un site WSS 3.0. Comme vous pouvez le voir, ce fichier .aspx renvoie à la page default.master, tout comme nous l'évoquions précédemment. Cependant, il hérite aussi explicitement de la classe de base WebPartPage et ajoute deux contrôles WebPartZone dans PlaceHolderMain.
Lorsque vous créez une page WebPart pour une application ASP.NET 2.0 standard, vous devez ajouter une logique qui interagit avec le contrôle WebPartManager afin de gérer le mode d'affichage WebPart. En général, vous devez également ajouter de manière explicite des composants EditorPart et CatalogPart à cette page, en plus de la mise en page HTML nécessaire à leur hébergement. Bien heureusement, vous n'avez pas besoin d'effectuer toutes ces opérations lorsque vous créez des pages de contenu pour un site WSS 3.0. Au contraire, vous héritez de la classe WebPartPage définie dans l'espace de noms Microsoft.SharePoint.WebPartPages, si bien que cette dernière fait tout le travail pour vous en arrière-plan.
Développement de composants WebPart personnalisés
La méthode la plus couramment utilisée pour la création de composants WebPart dédiés aux sites WSS 3.0 consiste à créer des composants WebPart de style ASP.NET. Au minimum, cette approche implique de créer une classe héritant de la classe de base WebPart définie dans l'espace de noms System.Web.UI.WebControls.WebParts ainsi que de remplacer la méthode RenderContents. Si vous souhaitez ajouter des propriétés WebPart persistantes, utilisez la même technique que pour ASP.NET.
La définition WebPart illustrée à la figure 8 ne possède aucune dépendance vis-à-vis du fichier Microsoft.SharePoint.dll, ce qui signifie qu'elle peut être utilisée tout aussi bien dans une application ASP.NET standard que sur un site WSS 3.0. Néanmoins, dans la majorité des cas, vous souhaiterez sans doute ajouter une référence au fichier Microsoft.SharePoint.dll de façon à ce que le code de vos composants WebPart puisse également utiliser le modèle objet WSS 3.0 pour la programmation.
WSS 3.0 a par ailleurs été conçu pour prendre en charge les composants WebPart créés pour l'environnement WSS 2.0. Ces anciens composants WebPart WSS héritent de la classe de base WebPart du fichier Microsoft.SharePoint.dll qui est définie dans l'espace de noms Microsoft.SharePoint.WebPartPages.
La classe WebPart de l'ancienne version du fichier Microsoft.SharePoint.dll a été conçue de manière à hériter de la classe de contrôle ASP.NET, comme le montre la figure 9. Cependant, vous noterez que la classe WebPart de la nouvelle version du fichier Microsoft.SharePoint.dll a été modifiée de manière à hériter non pas de cette classe, mais de la classe WebPart ASP.NET. Cette technique consistant à changer la classe de base dans une nouvelle version d'un assembly est connue sous le nom de « relocalisation ». La relocalisation de la classe de base WebPart du fichier Microsoft.SharePoint.dll est l'un des éléments clés permettant la prise en charge des anciens composants WebPart dans un environnement WSS 3.0.
Si vous examinez attentivement le fichier web.config standard d'une application Web WSS 3.0, vous constaterez qu'il contient des éléments de configuration permettant de rediriger les références de l'ancienne version du fichier Microsoft.SharePoint.dll vers la nouvelle version. Alliée à la relocalisation de la classe de base WebPart, cette redirection permet aux DLL WebPart conçues pour l'environnement WSS 2.0 de s'exécuter au sein de l'environnement 3.0 sans aucune recompilation.
Figure 9 : Classe WebPart relocalisée
Si vous décidez de convertir un projet WebPart 2.0 en un projet Visual Studio® 2005, vous pouvez continuer à faire évoluer votre code en utilisant le même style que par le passé, sans que cela ne crée de dysfonctionnements. Cependant, une fois que vous êtes passé à Visual Studio 2005 et que vous avez transféré l'ancienne référence à Microsoft.SharePoint.dll vers la nouvelle version WSS 3.0, vous disposez d'une autre option. En effet, puisque la classe de base WebPart ASP.NET fait désormais partie intégrante de la hiérarchie d'héritage, vous pouvez modifier certains aspects de votre classe WebPart de style WSS de la même manière que s'il s'agissait d'une classe WebPart de style ASP.NET. On parle alors de composant WebPart hybride.
Améliorations apportées au stockage de contenu
WSS 2.0 présentait un autre inconvénient pour les développeurs : de nombreuses fonctions importantes offertes par les bibliothèques de documents n'étaient pas prises en charge par les listes. Par exemple, les bibliothèques de documents prenaient en charge les événements et le contrôle des versions, ce qui n'était pas le cas des listes. Dans WSS 3.0, les listes proposent la majorité des fonctions des bibliothèques de documents (contrôle des versions, événements, dossiers, etc.). Listes et bibliothèques de documents partagent également de nouvelles fonctionnalités telles que l'exposition des données via des flux RSS automatiques.
WSS 3.0 offre une nouvelle fonction d'indexation des colonnes qui répond à certains problèmes de performances dont souffraient les bibliothèques de documents et les listes dans WSS 2.0. Vous pouvez ainsi ajouter un index à n'importe quelle colonne à partir de la page de paramétrage d'une liste ou d'une bibliothèque de documents. Notez cependant que cette opération ne crée pas à proprement parler un index physique dans SQL Server. Elle crée à la place une table contenant l'ID entier de l'élément de liste ou du document ainsi que la valeur de la colonne indexée. WSS utilise ensuite cette table pour améliorer les performances des données retournées en fonction des différentes vues, notamment lorsque vous utilisez une vue exploitant un filtre basé sur la colonne indexée.
De nombreux développeurs ont exprimé le désir de pouvoir travailler avec des champs WSS à un niveau inférieur afin d'obtenir un meilleur contrôle sur la validation et le rendu des champs. À cette fin, WSS 3.0 propose de nouveaux types de champs extensibles. Vous pouvez créer un type de champ extensible en écrivant une classe en C# ou Visual Basic® qui hérite de l'un des types de champs SharePoint intégrés, tels que SPFieldText ou SPFieldNumber. Un type de champ extensible peut également exploiter un contrôle utilisateur ASP.NET qui renferme vos contrôles Web préférés, vous permettant ainsi d'utiliser les mêmes techniques pour la validation et l'initialisation des contrôles que celles offertes par les applications ASP.NET.
WSS 3.0 se distingue encore par une autre innovation de taille : des colonnes de sites personnalisées. Une colonne de site est une définition réutilisable pouvant être appliquée à différentes listes. Elle définit le nom d'une colonne, son type de champ sous-jacent et d'autres caractéristiques telles que la valeur par défaut, le formatage et la validation. Une fois qu'une colonne de site est définie, vous pouvez l'utiliser pour configurer la structure des listes définies par l'utilisateur. L'un des avantages les plus évidents de cette option est qu'il suffit de mettre à jour la colonne de site à un seul emplacement pour que les modifications soient appliquées à l'ensemble des listes utilisant cette colonne. Une colonne de site est définie dans les limites d'un site mais elle est visible à partir de tous les sites enfants. Vous pouvez donc créer une colonne de site utilisable sur toute une collection de sites en la définissant dans le site se trouvant au niveau le plus élevé.
Les colonnes de sites vous donnent la possibilité de lancer des consultations de champs sur différents sites, ce qui n'était pas possible sans écrire un code personnalisé dans les versions précédentes de SharePoint. Vous pouvez de cette manière créer dans un site de premier niveau une colonne de site qui lancera une consultation dans une liste de ce site. Vous pouvez ensuite créer au sein des sites enfants d'autres listes qui utiliseront cette colonne de site pour effectuer des consultations dans la liste du site de premier niveau. Imaginons que vous souhaitiez stocker différents types de documents dans une seule bibliothèque de documents. Supposons ainsi que vous ayez besoin de stocker des présentations client, des propositions et des rapports. Vous souhaitez que chaque type de document possède son propre jeu de colonnes personnalisées ainsi qu'un gestionnaire d'événements spécifique. Dans WSS 2.0, vous pouviez uniquement ajouter des colonnes et des gestionnaires d'événements supplémentaires à la bibliothèque de documents elle-même, ce qui avait un impact sur chacun des documents qu'elle contenait. Qui plus est, une bibliothèque de documents pouvait être associée à un seul modèle de document.
Pour résoudre ce problème, WSS 3.0 propose un nouveau système de stockage haute puissance, désigné sous le terme de « types de contenu ». Un type de contenu est un type WSS réutilisable et flexible qui définit la forme et le comportement d'un élément de liste ou d'un document dans une bibliothèque de documents. Par exemple, pour un document de présentation client, vous pouvez créer un type de contenu doté d'un groupe de colonnes unique, d'un gestionnaire d'événements et d'un modèle de document spécifique. Vous pouvez ensuite créer un deuxième type de contenu pour un document de proposition client fondé sur un groupe de colonnes différent, un workflow et un modèle de document distinct. Enfin, vous pouvez créer une nouvelle bibliothèque de documents et configurer cette dernière de manière à ce qu'elle prenne en charge ces deux types de contenu. Il s'agit là d'une amélioration notable, puisqu'elle vous permet de gérer des types de contenu hétérogènes au sein des listes et bibliothèques de documents.
Gestionnaires d’événements
Dans WSS 2.0, les événements étaient compatibles avec les bibliothèques de documents, mais non avec les listes. Par ailleurs, WSS 2.0 prenait en charge uniquement les événements asynchrones survenant après l'exécution d'une action utilisateur dans la base de données SQL Server. Les développeurs étaient dans l'incapacité d'annuler l'action d'un utilisateur au sein d'un gestionnaire d'événements.
WSS 3.0 améliore la gestion des événements en conservant cette prise en charge des événements asynchrones et en la complétant par une prise en charge des événements synchrones qui vous permet d'annuler les actions des utilisateurs. Vous avez ainsi la possibilité d'empêcher un utilisateur de supprimer un document qui a été approuvé ou de créer une commande contenant une date de commande située dans le futur. En outre, les événements sont pris en charge au niveau des éléments de liste tout comme au niveau des documents des bibliothèques de documents.
Pour créer un gestionnaire d'événements, vous devez écrire une classe personnalisée qui hérite de l'une des classes de récepteurs WSS et remplacer les méthodes de gestion des événements. De cette façon, pour gérer les événements de mise à jour liés aux éléments d'une liste, vous pouvez créer une classe qui hérite de la classe SPItemEventReceiver et remplacer la méthode ItemUpdating (voir figure 10).
Vous pouvez associer le gestionnaire d'événements à une liste précise ou à une bibliothèque de documents spécifique en écrivant du code dans le modèle objet ou en définissant un récepteur d'événements dans une fonctionnalité WSS. Vous pourriez par exemple associer ce récepteur à une liste au moyen d'un code similaire à celui-ci :
Dim list As SPList = web.Lists("Orders")
list.EventReceivers.Add(SPEventReceiverType.ItemAdding, _
"[Fully-qualified Assembly name]", "Litware.MyReceiver")
Les classes de récepteurs WSS utilisent une convention d'affectation de noms pour les méthodes substituables qui établit une distinction entre les événements synchrones et asynchrones. Ainsi, ItemUpdating est un événement synchrone annulable déclenché avant que la modification ne soit appliquée à la base de données de contenu. Ces événements synchrones offrent un moyen unique de valider les valeurs des colonnes, comme le montre le gestionnaire d'événements de la figure 10.
Il existe un événement asynchrone complémentaire appelé ItemUpdated, qui survient après l'écriture d'une modification dans la base de données de contenu. À la différence des événements synchrones, les événements asynchrones ne prennent pas en charge l'annulation des actions des utilisateurs. Ils permettent à la place d'effectuer certaines opérations requises une fois qu'un changement a été apporté à un document ou à un élément de liste : assignation de la valeur d'une colonne calculée, envoi d'une notification par e-mail, etc.
Outre les événements afférents aux éléments de liste et aux documents, WSS 3.0 prend en charge d'autres types d'événements, notamment les événements de liste qui surviennent lorsqu'un utilisateur change une définition de liste. Vous avez ainsi la possibilité d'annuler l'action d'un utilisateur visant à supprimer ou renommer une colonne d'une de vos listes personnalisées. Certains événements se déclenchent également lorsque quelqu'un supprime ou déplace un site d'une collection de sites.
Workflows dans le WSS
Ces derniers temps, les applications de workflow ont fait l'objet d'une attention toute particulière de la part de l'équipe Microsoft. Les composants du runtime WinFX®, qui devraient être publiés en même temps que Windows Vista™, ajoutent une infrastructure complète (Windows Workflow Foundation) dédiée à la création d'applications de type workflow. Cette infrastructure comprend un moteur, des composants enfichables capables de rendre persistant l'état de workflow et un concepteur Visual Studio permettant de créer en toute facilité des workflows personnalisés en glissant-déposant des composants (ou « activités ») sur une surface de conception de workflows.
WSS 3.0 tire parti de Windows Workflow Foundation de manière à offrir une structure mettant en relation la logique métier avec les éléments de liste et les documents. Il étend le modèle de workflow de base en associant à chaque workflow une liste des tâches et un historique. Ce faisant, il améliore la définition des responsabilités au niveau des workflows reposant sur une intervention humaine, telles que la révision ou l'approbation d'un document.
WSS et MOSS 2007 sont tous deux livrés avec des workflows installés et prêts à l'emploi. WSS 3.0 comprend des workflows de routage simples pour les actions de type modération et approbation. MOSS 2007 propose des workflows plus complexes pouvant prendre en charge des fonctions telles que les processus d'approbation liés à la gestion des contenus Web.
La création de workflows personnalisés représente un point d'extension évident pour les développeurs mettant au point des solutions métiers avec WSS et MOSS 2007. Outre la prise en charge standard des extensions Visual Studio pour Windows Workflow Foundation sont prévus un kit de développement de logiciels de workflow spécifique à WSS et un kit de démarrage comprenant des modèles de projets Visual Studio pour la création de workflows personnalisés dédiés aux sites WSS.
SharePoint Designer permet également la création de workflows personnalisés pour les sites WSS 3.0. Cette option vise tout autant (voire plus) les utilisateurs expérimentés que les développeurs car elle offre un accès à un assistant et permet de mettre en relation la logique métier avec les éléments de liste et les documents d'un site de production.
Définitions de sites, fonctionnalités et solutions
Les développeurs ayant utilisé WSS 2.0 comme plate-forme de création de solutions métiers ont pu constater que le fait de travailler avec des définitions de sites de niveau inférieur optimise le contrôle et la réutilisabilité. Une définition de site est un répertoire situé sur le serveur Web principal. Il contient des fichiers XML et des modèles de pages .aspx qui définissent la présentation du site (schémas de listes, mise en page, etc.). Le langage utilisé par de nombreux fichiers de définitions de sites est un langage basé sur XML appelé CAML (Collaborative Application Markup Language).
Cependant, cette stratégie présentait plusieurs problèmes dans la version WSS 2.0. En premier lieu, les fichiers XML contenus dans les définitions de sites de cette version étaient mal factorisés, si bien qu'ils étaient difficiles à manipuler. Deuxièmement, il n'était pas possible de modifier une définition de site une fois qu'elle avait été utilisée pour créer des sites. En d'autres termes, il n'existait aucune technique basée sur les définitions de sites permettant d'étendre les fonctionnalités d'un site WSS 2.0 existant. En troisième lieu, les définitions de sites et les assemblys personnalisés dont elles dépendaient devaient être transférés sur chaque serveur Web principal d'une batterie de serveurs sans aucun soutien de l'infrastructure WSS. Enfin, WSS 2.0 ne permettait pas de localiser les définitions de sites, ce qui était particulièrement frustrant pour les sociétés souhaitant internationaliser leurs solutions métiers.
La première avancée significative de WSS 3.0 sur ce plan est représentée par l'introduction de fonctionnalités. Une fonctionnalité est similaire à une définition de site : il s'agit d'un répertoire contenant des fichiers XML basés sur CAML et des modèles de pages. Cependant, les fonctionnalités offrent une approche beaucoup plus modulaire car vous n'avez pas besoin de définir la présentation entière d'un site. Au contraire, vous pouvez utiliser une fonctionnalité pour définir un élément de site unique tel qu'une définition de liste personnalisée ou des commandes de menus devant être affichées dans l'un des menus WSS standard.
Il est de plus possible d'activer des fonctionnalités sur un site existant. Vous pouvez ainsi créer une fonctionnalité qui définit un type de liste personnalisé, une instance de ce type de liste ainsi qu'un gestionnaire d'événements ou un workflow correspondant à cette instance de liste. Une fois la fonctionnalité installée, vous pouvez l'activer sur n'importe quel site d'une batterie de serveurs au moyen de l'interface utilisateur WSS, de la ligne de commande ou bien encore d'un code personnalisé écrit dans le modèle objet WSS. À partir du moment où la fonctionnalité est activée, le site inclura votre nouvelle liste personnalisée ainsi que tous les comportements que vous souhaitez lui associer.
Les fonctionnalités simplifient également le développement des définitions de sites. Dans WSS 2.0, chaque définition de liste devait être spécifiée dans le contexte d'une définition de site. Dans WSS 3.0, chaque définition de liste peut être constituée en une fonctionnalité indépendante. La création des définitions de site s'en trouve simplifiée, puisqu'elle peut tirer parti des références des fonctionnalités. C'est ainsi l'approche qui a été adoptée pour tous les types de liste fournis dans le cadre des services de collaboration WSS.
WSS 3.0 introduit un nouveau système de déploiement appelé « solution » qui est similaire aux packages WebPart dans le sens où il s'agit d'un fichier .cab agrégé dans lequel se trouvent des instructions au format XML et des fichiers devant être déployés sur chaque serveur Web principal. Cependant, ces solutions sont bien plus que de simples packages WebPart puisqu'elles prennent en charge le déploiement des fonctionnalités, des définitions de site et des assemblys y afférents utilisés pour les gestionnaires d'événements et les workflows.
Les solutions WSS 3.0 simplifient également l'envoi des fichiers de déploiement vers chaque serveur Web d'une batterie de serveurs. Un administrateur ajoute une solution à une batterie de serveurs WSS, laquelle copie le fichier de solution .cab dans la base de données de configuration. Ensuite, l'administrateur exécute une commande de déploiement de la solution. WSS lance alors une tâche programmée pour envoyer le fichier de solution .cab file à chaque serveur Web en vue d'une installation.
La nouvelle fonction de localisation est également une amélioration qui sera appréciée par les développeurs WSS. Fondée sur l'infrastructure de localisation d'ASP.NET 2.0, cette fonction permet de créer des définitions de site et des fonctionnalités dans un mode indépendant de la langue et de maintenir des chaînes littérales dans les fichiers .resx. Au sein des fichiers XML et des fichiers de modèles de pages .aspx d'une fonctionnalité ou d'une définition de site, vous pouvez obtenir la valeur d'une chaîne nommée qui a été localisée en un fichier .resx au moyen de la syntaxe ASP.NET standard.
<%$Resources:Litware,MyString%>
Sécurité de type Internet
Dans WSS 2.0, l'authentification était fondée sur les comptes Windows et les ID de sécurité qui y étaient associés. D'un point de vue pratique, cela signifiait que WSS 2.0 fonctionnait étroitement avec Active Directory®, sauf pour les déploiements de petite taille. Cette dépendance ne représentait pas un problème pour les sociétés qui déployaient Active Directory lorsqu'elles commençaient à utiliser WSS 2.0 et SharePoint Portal Server 2003 pour créer leurs solutions intranet. Mais pour les sociétés développant des solutions extranet, il s'agissait là d'une toute autre histoire. L'association étroite de WSS et d'Active Directory contraignait les sociétés à créer et à gérer des comptes de domaine pour les utilisateurs externes à la société tels que les vendeurs et les clients.
WSS 3.0 met fin à ces problèmes en offrant un tout nouveau système d'authentification fondé sur la nouvelle infrastructure d'authentification d'ASP.NET 2.0. Si vous ne souhaitez pas posséder de comptes utilisateur pour les sites WSS et MOSS 2007 au sein d'Active Directory, il vous suffit de créer ou d'acquérir un fournisseur d'authentification ASP.NET conçu pour stocker et gérer les comptes utilisateur dans un référentiel d'identité distinct.
Par exemple, ASP.NET 2.0 vous est livré avec un fournisseur d'authentification des formulaires qui vous permet de gérer des comptes utilisateur dans une base de données SQL Server. Ce fournisseur d'authentification peut être configuré pour une utilisation sur un site WSS. Avec un minimum d'efforts, vous pouvez mettre en ligne un site WSS qui permettra aux utilisateurs inconnus de s'inscrire en tant que membres. Grâce à ASP.NET 2.0, vous pouvez créer et gérer des comptes utilisateur en toute facilité, mais aussi permettre aux utilisateurs de modifier et de réinitialiser leurs mots de passe.
Conclusion
Nous avons abordé dans cet article la majorité des améliorations de WSS 3.0 visant les développeurs. Vous en découvrirez d'autres à mesure que vous travaillerez avec cet outil. Il ne fait d'ores et déjà aucun doute que l'équipe WSS a accompli ici un travail remarquable : non seulement elle a prêté une oreille attentive aux commentaires des développeurs sur la version précédente, mais elle a su y répondre en dotant la nouvelle version de fonctionnalités inédites.
Ted Pattison est auteur et instructeur. Il dispense des formations pratiques par le biais de sa société, Ted Pattison Group. Ted mène actuellement des recherches dans le cadre de la rédaction d'un nouveau livre traitant des technologies de serveur Windows SharePoint Services 3.0 et Office 12.
Extrait du numéro de juillet 2006 de MSDN Magazine.