Office Space
Fonctionnalités pour SharePoint
Ted Pattison
Téléchargement du code disponible sur: OfficeSpaceFeature2007_05.exe (190 KB)
Browse the Code Online
Dans mon précédent article Office Space, j'ai abordé les formats de fichier XML ouvert Office. En particulier, j'ai expliqué comment écrire le code sous-jacent d'une page ASP.NET pour produire un fichier .docx pour Microsoft® Word à l'aide de l'API d'empaquetage fournie par Microsoft .NET Framework 3.0. Dans l'édition de ce mois, je m'appuie sur ce que j'ai déjà présenté au sujet des formats de fichier XML ouvert Office. Je cherche à intégrer ce code dans une solution d'entreprise qui peut être déployée dans Windows® Sharepoint® Services (WSS) 3.0 ou Microsoft Office SharePoint Server (MOSS) 2007.
L'intérêt de l'article Office Space du mois est de présenter les composants fondamentaux utilisés pour créer des solutions métier avec WSS et MOSS. J'y explique ce qu'est une « fonctionnalité » WSS et indique comment générer une fonctionnalité qui automatise la création de listes et de bibliothèques de documents sur un site. Dans le cadre de cette explication, j'ajoute une page d'application personnalisée à la solution métier personnalisée. Elle contient le code Visual Basic® nécessaire à la génération de documents Word à partir de données qui se trouvent dans des listes Sharepoint et à l'enregistrement de ces documents dans une bibliothèque de documents Sharepoint.
Qu'est-ce qu'une « fonctionnalité » ?
Lors du développement de solutions d'entreprise personnalisées pour WSS et MOSS, vous devez d'abord bien comprendre les fonctionnalités (et je ne fais pas référence au jeu de fonctionnalités dans son ensemble). Les fonctionnalités constituent une nouvelle innovation axée sur les développeurs, qui a été ajoutée à WSS 3.0. Fondamentalement, elles offrent un mécanisme de définition des éléments d'un site, lequel peut être activé automatiquement dans le contexte d'un site cible ou d'une collection de sites cible. Les types d'élément pouvant être définis par une fonctionnalité sont les instances de liste, les types de liste, les commandes de menu, les modèles de page, les instances de page, les gestionnaires d'événements et les flux de travail. L'exemple sur lequel je m'appuie dans cet article utilise une fonctionnalité appelée OfficeSpaceFeature, qui crée une liste et une bibliothèque de documents, et ajoute une option de menu personnalisée au menu Actions du site standard de WSS, ce qui permet à l'utilisateur d'accéder à une page d'application personnalisée.
Une fonctionnalité comporte un répertoire créé dans un répertoire système WSS spécial situé dans le système de fichiers de chaque serveur Web frontal. Le répertoire d'une fonctionnalité contient un ou plusieurs fichiers XML, qui contiennent des données CAML (automatiquement). Par convention, chaque répertoire de fonctionnalité contient un fichier de manifeste appelé feature.xml. Ce fichier définit les attributs de haut niveau de la fonctionnalité, tels que son identifiant et son titre convivial.
Outre le fichier feature.xml, une fonctionnalité contient généralement un ou plusieurs fichiers XML supplémentaires (elements.xml, par exemple), qui définissent les éléments réels qui composent la fonctionnalité. Le répertoire peut également contenir d'autres types de fichiers pour des choses comme les définitions de liste et modèles de pages et des ressources comme les images, les feuilles de style en cascade et Javascript. Le répertoire de fonctionnalité de mon exemple inclut un fichier supplémentaire, qui sert de modèle de document pour une bibliothèque de documents.
Pour connaître rapidement les fonctionnalités, examinez le jeu de fonctionnalités standard inclus avec l'installation WSS de base. La figure 1 illustre l'apparence d'un exemple de répertoire FEATURES une fois que WSS est installé. Comme vous pouvez le constater, chaque fonctionnalité possède son propre répertoire. Le répertoire FEATURES se présente différemment si MOSS est installé car celui-ci inclut plus de 100 fonctionnalités.
Figure 1 Répertoire FEATURES standard (Cliquer sur l'image pour l'agrandir)
Une fois que vous avez créé le répertoire avec tous les fichiers composant la fonctionnalité, vous devez ensuite l'installer avec WSS à l'échelle de la batterie de serveurs. Lorsqu'une fonctionnalité a été installée avec WSS, elle peut être activée dans le contexte d'un site ou d'une collection de sites à l'aide d'un page d'administration accessible via la page Paramètres du site.
Les éléments à télécharger pour cet article incluent un projet Visual Studio® appelé OfficeSpaceFeature, qui comporte une fonctionnalité du même nom. La figure 2 présente une vue de l'Explorateur de solutions pour vous donner une idée des types de fichier impliqués lorsque vous créez un projet Visual Studio afin de développer une fonctionnalité personnalisée pour WSS ou MOSS. J'ai créé l'exemple de cet article sous forme de projet de DLL Visual Basic. Vous pouvez, bien entendu, utiliser un projet de DLL C# à la place si vous préférez. Le code géré dans la DLL de l'assembly doit être compilé avec un nom fort et installé dans le Global Assembly Cache (GAC) pour pouvoir être utilisé pour les gestionnaires d'événements de la fonctionnalité.
Figure 2 OfficeSpaceFeature
Structure d'une fonctionnalité
Avant d'examiner le fichier feature.xml, rappelez-vous que les fichiers de cette fonctionnalité doivent être déployés dans leur propre répertoire à l'intérieur du répertoire système WSS appelé FEATURES. Le répertoire FEATURES se trouve dans un autre répertoire système WSS, appelé TEMPLATE, comme illustré à la figure 1. Compte tenu des exigences de déploiement de la fonctionnalité, il convient de créer une hiérarchie parallèle de dossiers dans un projet Visual Studio utilisé pour développer une fonctionnalité WSS. Cela facilite la copie des fichiers de la fonctionnalité dans l'emplacement approprié et leur test dans le cadre de votre travail de développement.
Commencez par ajouter un dossier appelé TEMPLATE dans le répertoire principal du projet actuel. Ensuite, créez un autre répertoire dans le répertoire TEMPLATE, appelé FEATURES. Enfin, créez un autre répertoire dans le répertoire FEATURES en utilisant le nom du projet de fonctionnalité. Dans le cas présent, le nom du projet et du répertoire est OfficeSpaceFeature, comme vous pouvez le constater à lafigure 2.
Passons maintenant au contenu CAML du fichier feature.xml. Le fichier feature.xml sert de manifeste de fonctionnalité dans lequel vous spécifiez les informations qui définissent les attributs de haut niveau de la fonctionnalité proprement dite. Le fichier feature.xml de mon exemple de fonctionnalité se présente comme illustré à la figure 3.
Figure 3 Exemple de fichier Feature.xml<?xml version=”1.0” encoding=”utf-8” ?>
<Feature Id=”AAEC2E08-1CCF-4712-AE5E-A33BEA53A325”
Title=”A Sample Office Space Feature”
Description=
“Demoware from Ted Pattison’s Office Space column in MSDN Magazine”
Version=”1.0.0.0”
Scope=”Web”
ImageUrl=”OfficeSpace/PithHelmet.gif”
ReceiverAssembly=”OfficeSpaceFeature, [full strong name]”
ReceiverClass=”OfficeSpaceFeature.FeatureReceiver”
xmlns=”http://schemas.microsoft.com/sharepoint/”>
<ElementManifests>
<ElementManifest Location=”elements.xml” />
</ElementManifests>
</Feature>
Vous pouvez constater qu'une fonctionnalité est définie à l'aide d'un élément Feature, qui contient plusieurs attributs tels que Id, Title, Description, Version, Scope, Hidden et ImageUrl. Vous devez créer un nouveau GUID pour l'attribut Id afin que votre fonctionnalité puisse être identifiée de manière unique. Vous créez les attributs Title et Description de la fonctionnalité à l'aide de texte convivial. Ces attributs apparaissent directement aux utilisateurs dans les pages d'administration WSS, qui sont utilisées pour activer et désactiver les fonctionnalités.
L'attribut Scope (Portée) définit le contexte dans lequel la fonctionnalité peut être activée et désactivée. La fonctionnalité que je crée possède une portée correspondant à Web, ce qui signifie qu'elle peut être activée et désactivée dans le contexte d'un site. Si vous affectez une valeur Site à l'attribut Scope, la fonctionnalité peut être ensuite activée et désactivée dans la portée d'une collection de sites. Les deux autres valeurs Scope possibles pour définir une fonctionnalité sont WebApplication et Farm.
Comme vous pouvez le constater, l'attribut Hidden prend la valeur FALSE. Cela signifie qu'une fois installée au sein de la batterie de serveurs, la fonctionnalité est visible par des utilisateurs qui peuvent avoir envie de l'activer. Si vous créez une fonctionnalité avec la valeur d'attribut Hidden TRUE, la fonctionnalité est masquée dans la liste de fonctionnalités disponibles affichées pour les utilisateurs. Les fonctionnalités masquées doivent être activées dans la ligne de commande, par le biais de code personnalisé ou via une dépendance d'activation avec une autre fonctionnalité.
Vous avez peut-être remarqué que l'attribut ImageUrl possède une valeur qui pointe vers une des images graphiques incluses dans l'installation WSS de base. Cette image sera affichée en regard de la fonctionnalité dans l'interface utilisateur.
La dernière partie du fichier feature.xml illustrée à la figure 3 est l'élément ElementManifest. Cet élément contient des éléments ElementManifest internes, qui renvoient à d'autres fichiers XML dans lesquels vous définissez les éléments qui composent la fonctionnalité. Dans ce cas, il y a un seul élément ElementManifest, qui utilise l'attribut Location pour pointer vers un fichier appelé element.xml.
Notez que lorsque vous ajoutez et modifiez du code XML dans des fichiers CAML tels que feature.xml et elements.xml, vous devez ajouter la prise en charge pour IntelliSense® pour schémas XML. Dans le répertoire TEMPLATE se trouve un répertoire appelé XML qui contient plusieurs schémas XML, dont un schéma appelé wss.xsd. Si vous associez ce fichier de schéma à des fichiers de fonctionnalité tels que feature.xml et element.xml, Visual Studio met IntelliSense à disposition, ce qui facilite grandement la création de fonctionnalités personnalisées.
Il est maintenant temps d'examiner le contenu du fichier element.xml. Imaginez que vous souhaitiez instancier une bibliothèque de documents chaque fois que la fonctionnalité est activée. Vous pouvez créer un fichier elements.xml, qui se présente comme celui illustré à la figure 4.
Figure 4 Exemple de fichier Elements.xml<Elements xmlns=”http://schemas.microsoft.com/sharepoint/”>
<ListInstance
FeatureId=”00BFEA71-E717-4E80-AA17-D0C71B360101”
TemplateType=”101”
Id=”CustomerLetters”
Description=”Letters sent to customers”
OnQuickLaunch=”True”
Title=”Customer Letters”
Url=”CustomerLetters”>
</ListInstance>
<Module Name=”LetterTemplate” List=”101” Url=”CustomerLetters/Forms”>
<File Url=”LetterTemplate.docx” Type=”GhostableInLibrary” />
</Module>
<!-- more elements to come... -->
</Elements>
Le premier élément présenté ici, un élément ListInstance, est utilisé pour créer une instance d'une liste ou d'une bibliothèque de documents. Notez que l'élément ListInstance contient un élément FeatureId et un élément TemplateType permettant de pointer vers un type de liste spécifique et l'ID de la fonctionnalité dans laquelle ce type de liste est défini. Dans le cas présent, j'utilise le type de bibliothèque de documents WSS standard, qui possède un identifiant TemplateType de 101 pour créer une bibliothèque de documents appelée Customer Letters. Dans l'élément ListInstance, il y a également un élément Module, qui contient un élément File interne. Cet élément File est utilisé pour configurer un modèle de document pour la bibliothèque de documents. Plus précisément, cet élément File fournit à WSS des instructions pour copier un fichier appelé LetterTemplate.docs du répertoire de fonctionnalité vers le site WSS. De ce fait, il est accessible aux utilisateurs.
Bien que la logique déclarative du fichier elements.xml fournisse pratiquement tout ce dont vous avez besoin pour créer des éléments dans un site WSS, elle doit souvent être accompagnée d'une logique de programmation. Pour mon exemple, j'ai créé une bibliothèque de documents et j'ai configuré un fichier qui sert de modèle de document. Cependant, je dois fournir du code supplémentaire pour programmer dans le modèle objet WSS afin d'associer le modèle de document à la bibliothèque de documents.
Dans le fichier feature.xml, vous remarquez que l'élément Feature contient deux attributs appelés ReceiverAssembly et ReceiverClass. Ces attributs sont configurés de sorte à pointer vers une classe gérée appelée récepteur de fonctionnalité, qui fournit des gestionnaires d'événements. Les gestionnaires d'événements d'une classe de récepteur de fonctionnalité sont déclenchés lorsqu'une fonctionnalité est installée ou activée, ou lorsqu'une fonctionnalité est désinstallée ou désactivée. Vous créez un récepteur de fonctionnalité en créant une classe qui hérite de la classe SPFeatureReceiver comme illustré à lafigure 5.
Figure 5 Classe qui hérite de SPFeatureReceiverImports Microsoft.SharePoint
Public Class FeatureReceiver : Inherits SPFeatureReceiver
Public Overrides Sub FeatureActivated( _
ByVal properties As SPFeatureReceiverProperties)
‘*** fires when feature is activated
End Sub
Public Overrides Sub FeatureDeactivating( _
ByVal properties As SPFeatureReceiverProperties)
‘*** fires when feature is deactivated
End Sub
Public Overrides Sub FeatureInstalled( _
ByVal properties As SPFeatureReceiverProperties)
‘*** fires when feature is installed
End Sub
Public Overrides Sub FeatureUninstalling( _
ByVal properties As SPFeatureReceiverProperties)
‘*** fires when feature is uninstalled
End Sub
End Class
Pour mon exemple, je ne fournis du code que dans le gestionnaire d'événements activé par la fonctionnalité. Ce code utilise le modèle d'objet WSS pour associer le modèle de document à la bibliothèque de documents Customer Letters. Dans le gestionnaire d'événements, cette opération est effectuée en obtenant une référence SPWeb au site actuel, puis une référence SPDocumentLibrary à la bibliothèque de documents de cible. Cela permet de modifier la propriété DocumentTemplateUrl et d'enregistrer cette modification à l'aide d'un appel de la méthode Update, comme suit :
Public Overrides Sub FeatureActivated( _
ByVal properties As SPFeatureReceiverProperties)
Dim site As SPWeb = CType(properties.Feature.Parent, SPWeb)
Dim libLetterTemplates As SPDocumentLibrary
libLetterTemplates = CType(site.Lists(“Customer Letters”), _
SPDocumentLibrary)
Dim templateUrl As String = _
“CustomerLetters/Forms/LetterTemplate.docx”
libLetterTemplates.DocumentTemplateUrl = templateUrl
libLetterTemplates.Update()
End Sub
Déploiement et activation de la fonctionnalité
Maintenant que j'ai créé les fichiers feature.xml et elements.xml, je souhaite installer ma fonctionnalité pour la tester. L'installation de la fonctionnalité se déroule en quatre étapes. Pour commencer, je dois installer le fichier d'assembly appelé OfficeSpaceFeature.dll dans le Global Assembly Cache. Je copie ensuite le répertoire OfficeSpaceFeature dans le répertoire système FEATURES de WSS. J'exécute alors une opération Stsadm.exe pour installer la fonctionnalité avec WSS, et pour terminer j'active la fonctionnalité dans le contexte d'un site de WSS.
Les trois premières étapes peuvent être automatisées en créant un fichier de commandes appelé install.bat dans le répertoire principal de mon projet OfficeSpaceFeature en ajoutant les instructions de ligne de commande indiquées à la figure 6. Il est également possible d'automatiser la quatrième étape en exécutant l'opération ActivateFeature avec l'utilitaire Stsadm.exe. Cependant, je n'ai pas opté pour cette possibilité dans mon exemple car je souhaite vous guider tout au long du processus d'activation manuelle de la fonctionnalité, comme le feront les utilisateurs par le biais de l'interface utilisateur WSS.
Figure 6 Commandes d'automatisation de l'installation@SET TEMPLATEDIR=”c:\Program Files\Common Files\Microsoft Shared\
web server extensions\12\TEMPLATE”
@SET STSADM=”c:\Program Files\Common Files\Microsoft Shared\
web server extensions\12\bin\stsadm.exe”
@SET GACUTIL=”c:\Program Files\Microsoft Visual Studio 8\
SDK\v2.0\Bin\gacutil.exe”
Echo Installing OfficeSpaceFeature.dll in GAC
%GACUTIL% -if bin\debug\OfficeSpaceFeature.dll
Echo Copying source files to WSS \TEMPLATE directory
xcopy /e /y TEMPLATE\* %TEMPLATEDIR%
Echo Installing feature with WSS
%STSADM% -o installfeature -filename OfficeSpaceFeature\feature.xml -force
Echo Restarting IIS worker process
IISRESET
Lorsque j'ai terminé d'ajouter des instructions dans le fichier install.bat, je configure Visual Studio de sorte à l'exécuter chaque fois que je recrée le projet OfficeSpaceFeature. Je dois pour cela aller dans l'onglet Événements de génération des propriétés du projet et ajouter les instructions de ligne de commande d'événement après génération suivantes :
cd $(ProjectDir) Install.bat
La première ligne est nécessaire pour modifier le répertoire actif afin d'utiliser le répertoire du projet. La deuxième ligne exécute le fichier de commandes pour copier les fichiers de fonctionnalité dans l'emplacement approprié et installe ensuite la fonctionnalité avec l'opération InstallFeature de l'utilitaire Stsadm.exe de ligne de commande.
Maintenant que la fonctionnalité a été correctement installée, je peux l'activer dans le contexte d'un site. Vous pouvez effectuer cette opération sur tous les sites d'une batterie de serveurs WSS ou MOSS en accédant à la page Paramètres du site. Dans la section Administration du site, cliquez sur le lien qui contient le titre Fonctionnalités du site. Vous accédez à une page comme celle illustrée à la figure 7. Si vous travaillez sur une batterie de serveurs sur laquelle MOSS est installé, vous découvrirez bien plus de fonctionnalités que si vous travaillez sur une batterie qui ne comporte que WSS.
Figure 7 Activation et désactivation des fonctionnalités du site (Cliquer sur l'image pour l'agrandir)
Le titre et la description d'OfficeSpaceFeature apparaissent dans la page Fonctionnalités du site, et sont donc faciles à trouver. Je clique sur le bouton Activer. À ce stade, tous les éléments définis avec la logique déclarative dans le fichier elements.xml doivent être configurés dans le site actuel. WSS charge alors l'assembly de récepteur du Global Assembly Cache, crée une instance de la classe de récepteur et exécute la méthode FeatureActivated de la classe de récepteur.
Mon exemple est relativement simple. Cependant, comme vous pouvez l'imaginer, vous pouvez fournir une combinaison bien plus complexe d'éléments CAML déclaratifs et de code de modèle objet WSS dans FeatureActivated.
Extension de la fonctionnalité
Si vous examinez le fichier elements.xml, vous verrez qu'il existe un deuxième élément ListInstance. Il est utilisé pour créer une liste, appelée Clients, qui utilise le type de liste Contacts WSS intégré. Cet élément ListInstance démontre également comment ajouter des éléments par défaut à la liste afin de fournir des exemples de données client.
J'ai expliqué comment utiliser la logique déclarative CAML pour créer des listes et des bibliothèques de documents. Maintenant, je souhaite attirer votre attention sur le fait que vous pouvez créer une liste ou une bibliothèque de documents en utilisant du code personnalisé dans l'événement d'activation programmé selon le modèle d'objet WSS.
L'exemple de fonctionnalité inclut du code dans le gestionnaire d'événements FeatureActivated pour créer une autre liste à partir du type de liste personnalisé WSS standard appelé Letter Templates. Lorsque vous créez une liste à partir du type de liste personnalisé WSS standard, la liste contient automatiquement un champ appelé Titre. Mon code crée une deuxième colonne appelée Corps et utilise le modèle d'objet WSS pour ajouter des éléments de liste, qui fournissent les données utilisées comme modèles pour créer des lettres de client. Le code qui permet d'effectuer cette opération est reproduit à la figure 8.
Figure 8 Créer une liste et ajouter une nouvelle colonneDim template As SPListTemplate = site.ListTemplates(“Custom List”) Dim listLetterTemplatesID As Guid listLetterTemplatesID = site.Lists.Add(“Letter Templates”, “”, template) Dim listLetterTemplates As SPList = site.Lists(listLetterTemplatesID) listLetterTemplates.Fields.Add(“Body”, SPFieldType.Text, True) listLetterTemplates.OnQuickLaunch = False listLetterTemplates.Update() Dim newLetterTemplate As SPListItem newLetterTemplate = listLetterTemplates.Items.Add() newLetterTemplate(“Title”) = “Initial Greeting” newLetterTemplate(“Body”) = “Thanks for your recent interest in Litware.” newLetterTemplate.Update() newLetterTemplate = listLetterTemplates.Items.Add() newLetterTemplate(“Title”) = “Follow Up” newLetterTemplate(“Body”) = “Thanks for your recent purchase.” newLetterTemplate.Update()
Pages d'application personnalisées
Il est important de comprendre le concept des fonctionnalités et leur utilisation, mais il existe un second composant fondamental dans la conception et le développement de solutions pour WSS et MOSS. L'architecture WSS prend en charge un type de page spécial appelé page d'application. La page Paramètres de site standard (settings.aspx) constitue un bon exemple de page d'application. La page settings.aspx est déployée une fois sur chaque serveur Web frontal, mais est accessible à partir de n'importe quel site d'une batterie de serveurs WSS.
Les pages d'application sont déployées en tant que fichiers physiques sur le système de fichiers du serveur Web frontal dans un répertoire accessible au chemin suivant :
%PROGRAMFILES%\common files\microsoft shared \web server extensions\12\TEMPLATE\LAYOUTS
http://Litwareinc.com http://Litwareinc.com/sites/Vendors http://Litwareinc.com:1001/sites/Accounting
Une page d'application est accessible en ajoutant son chemin relatif dans le répertoire _layouts à la fin de l'adresse URL d'un site. Par exemple, vous pouvez accéder à la page Paramètres du site à l'aide de l'une de ces adresses URL :
http://Litwareinc.com/_layouts/settings.aspx http://Litwareinc.com/sites/Vendors/_layouts/settings.aspx http://Litwareinc.com:1001/sites/Accounting/_layouts/settings.aspx
Les pages d'application sont utilisées de façon intensive par l'équipe WSS pour la fourniture d'une bonne partie des fonctionnalités standard de configuration et d'administration des sites et des éléments. WSS prend également en charge les pages d'application personnalisée pour les solutions d'entreprise personnalisées. L'exemple de l'article du mois contient une page d'application personnalisée appelée Lettergenerator.aspx, qui est déployée comme toute autre page d'application dans le répertoire LAYOUTS.
Notez que Lettergenerator.aspx n'est pas déployé directement dans le répertoire LAYOUTS, mais dans un répertoire appelé OfficeSpace, qui se trouve dans le répertoire LAYOUTS. Il est recommandé de créer votre propre répertoire dans le répertoire LAYOUTS pour héberger les pages d'application personnalisées, pour éviter les éventuels conflits de dénomination.
Une page d'application est un type de page ASP.NET spécial, qui est généralement écrite de façon à hériter d'une classe de base appelée LayoutsPageBase et à se lier à la page de document maître standard, appelée application.master créée par l'équipe WSS. La figure 9 fournit un exemple de la page d'application personnalisée classique Hello World.
Figure 9 Page d'application personnalisée Hello World<%@ Assembly Name=”[Full assembly name for Microsoft.SharePoint]” %>
<%@ Page Language=”VB” MasterPageFile=”~/_layouts/application.master”
Inherits=”Microsoft.SharePoint.WebControls.LayoutsPageBase” %>
<%@ Import Namespace=”Microsoft.SharePoint” %>
<script runat=”server”>
Protected Overrides Sub OnLoad(e As EventArgs)
MyBase.OnLoad(e)
‘*** get current site and web objects through WSS object model
Dim siteCollection As SPSite = SPContext.Current.Site
Dim site As SPWeb = SPContext.Current.Web
‘*** now program against WSS objects within the current site
lblDisplay.Text = “Current site: “ & site.Title
End Sub
</script>
<asp:Content ID=”Main” runat=”server”
contentplaceholderid=”PlaceHolderMain” >
<!-- ADD HTML elements and controls here for page content -->
<asp:Label ID=”lblDisplay” runat=”server” />
</asp:Content>
Comme vous pouvez le constater, il est possible de créer une page d'application qui contient des contrôles ASP.NET standard avec des remplacements de code dans une page ASP.NET standard, comme OnLoad. Vous pouvez également ajouter des références d'assembly. Si vous ajoutez une référence à Microsoft.SharePoint.dll, vous pouvez programmer sur la collection de sites actuelle et le site actuel en obtenant une référence par le biais de la classe SPContext, comme c'est le cas à la figure 9.
Une fois que vous avez ajouté une page d'application personnalisée à une solution, vous devez permettre aux utilisateurs d'y accéder. En ajoutant un élément CustomAction à une fonctionnalité, vous pouvez fournir un lien ou une option de menu. Voici un exemple d'élément CustomAction utilisé dans l'exemple OfficeSpaceFeature pour ajouter une option de menu à la liste déroulante Actions du site :
<CustomAction
Id=”OfficeSpaceLetterGenerator”
GroupId=”SiteActions”
Location=”Microsoft.SharePoint.StandardMenu”
Sequence=”1001”
Title=”OfficeSpace Letter Generator”
Description=”Create letter using Open XML”
ImageUrl=”/_layouts/images/crtpage.gif” >
<UrlAction Url=”~site/_layouts/OfficeSpace/LetterGenerator.aspx”/>
</CustomAction>
Cet élément CustomAction ajoute l'option de menu personnalisée au menu standard Actions du site. L'élément UrlAction dans l'élément CustomAction fournit un attribut Url avec un chemin relatif vers ma page d'application personnalisée. La valeur de chaîne affectée à l'attribut Url possède un jeton dynamique sous forme de ~site. Elle est remplacée par WSS lors de l'exécution avec le chemin réel d'accès au site actuel.
Lorsque des utilisateurs sélectionnent l'option de menu personnalisée, ils sont redirigés vers la page d'application personnalisée appelée LetterGenerator.aspx, qui affiche l'interface utilisateur présenté illustrée à la figure 10. Un code de la méthode OnLoad de cette page permet de remplir deux zones de liste avec le client et le type de lettre de votre choix. Il utilise le modèle d'objet WSS pour extraire les données des deux listes créées lors de l'activation de la fonctionnalité. Il existe également deux boutons de commande qui permettent deux approches différentes de la création de lettres de clients sous forme de fichiers .docx, à l'aide du code présentée dans mon article précédent d'Office Space.
Figure 10 Page d'application personnalisée (Cliquer sur l'image pour l'agrandir)
Lorsque l'utilisateur clique sur l'un des boutons de commande, le gestionnaire d'événements exécute le code pour générer une lettre à l'aide des formats de fichier ouvert Office. Ce code est presque identique à celui présenté dans mon article précédent. Il diffère uniquement au niveau du code utilisé pour nommer le fichier et l'enregistrer dans la bibliothèque de documents WSS appelée Customer Letters.
Cet exemple décrit l'automatisation de la création de lettres de clients à l'aide des formats de fichier XML ouvert Office, et la synergie qui est observée entre WSS et ces formats de fichier.
Lorsque vous créez un fichier new.docx, vous devez disposer d'un emplacement dans lequel l'enregistrer. WSS propose un emplacement idéal pour stocker des documents, dans lequel ils peuvent être versionnés et mis à disposition d'une équipe qui travaille dans un environnement de collaboration. La figure 11illustre la bibliothèque de documents Customer Letters sur un site qui a activé ma fonctionnalité OfficeSpaceFeature.
Figure 11 Bibliothèque de documents Customer Letters (Cliquer sur l'image pour l'agrandir)
Résumé
L'article de ce mois présente les fonctionnalités et les pages d'application personnalisées : deux composants essentiels utilisés pour concevoir et mettre en œuvre des solutions pour WSS et MOSS. À ce stade, vous devez avoir savoir comment commencer à développer et à tester. Dans le prochain numéro d'Office Espace, j'aborderai l'empaquetage de solutions comme celle que je viens de décrire pour le déploiement dans un environnement de production.
Envoyez vos questions et commentaires à l'attention de Ted à l'adresse suivante : instinct@microsoft.com.
Ted Pattison est auteur, formateur et MVP Sharepoint. Il vit à Tampa en Floride. Il vient juste de terminer son manuel Inside Windows SharePoint Services 3.0 pour Microsoft Press. Il dispense également une formation Sharepoint avancée à des développeurs professionnels par le biais de son entreprise, Ted Pattison Group.
Keine Kommentare:
Kommentar veröffentlichen