MSDN Magazin > Home > Ausgaben > 2007 > May >  Office Space: Features für SharePoint
Office Space
Features für SharePoint
Ted Pattison

Codedownload verfügbar unter: OfficeSpaceFeature2007_05.exe (190 KB)
Browse the Code Online
In meinem vorigen Office Space-Artikel habe ich mich mit den Office Open XML-Dateiformaten beschäftigt. Ich habe insbesondere erklärt, wie Sie Code für eine ASP.NET-Seite schreiben können, um mithilfe der mit Microsoft .NET Framework 3.0 bereitgestellten Paket-API eine .docx-Datei für Microsoft® Word zu generieren. In diesem Monat baue ich auf den bereits beschriebenen Grundlagen zur Arbeit mit den Office Open XML-Dateiformaten auf. Dabei gehe ich auf die Integration dieses Codes in eine Geschäftslösung ein, die in Windows®SharePoint® Services (WSS) 3.0 oder Microsoft Office SharePoint Server (MOSS) 2007 bereitgestellt werden kann.
Der Schwerpunkt des Office Space-Artikels liegt in diesem Monat auf der Vorstellung der grundlegenden Bausteine, die Sie zum Erstellen von Geschäftslösungen mit WSS und MOSS verwenden können. Ich erkläre, was ein WSS-„Feature“ ist, und zeige Ihnen, wie Sie ein Feature erstellen können, das die Erstellung neuer Listen und Dokumentbibliotheken innerhalb einer Site automatisiert. Darüber hinaus füge ich der benutzerdefinierten Geschäftslösung eine benutzerdefinierte Anwendungsseite hinzu. Diese enthält den Visual Basic®-Code, der benötigt wird, um Word-Dokumente aus Daten in SharePoint-Listen zu generieren und diese Dokumente in einer SharePoint-Dokumentbibliothek zu speichern.

Was ist ein „Feature“?
Voraussetzung für das Entwickeln benutzerdefinierter Geschäftslösungen für WSS und MOSS ist ein gutes Verständnis des Featurekonzepts (und hiermit meine ich nicht den allgemeinen Featuresatz). Features sind eine Neuerung für Entwickler, die WSS 3.0 hinzugefügt wurde. Im Wesentlichen wird dadurch ein Mechanismus für die Definition von Websiteelementen bereitgestellt, die im Kontext einer Zielwebsite oder einer Zielwebsitesammlung automatisch aktiviert werden können. Zu den Elementtypen, die von einem Feature definiert werden können, gehören Listeninstanzen, Listentypen, Menübefehle, Seitenvorlagen, Seiteninstanzen, Ereignishandler und Workflows. Das Beispiel, das ich in diesem Artikel erläutern werde, umfasst ein Feature namens „OfficeSpaceFeature“, das eine Liste und eine Dokumentbibliothek erstellt und dem WSS-Standardmenü „Websiteaktionen“ ein benutzerdefiniertes Menüelement hinzufügt, das dem Benutzer die Navigation zu einer benutzerdefinierten Anwendungsseite ermöglicht.
Ein Feature besteht aus einem Verzeichnis, das in einem speziellen WSS-Systemverzeichnis innerhalb des Dateisystems jedes Front-End-Webservers erstellt wird. Das Verzeichnis für ein Feature enthält eine oder mehrere XML-basierte Dateien, die CAML (Collaborative Application Markup Language) enthalten. Der Konvention entsprechend enthält jedes Featureverzeichnis eine Manifestdatei namens „feature.xml“. Diese Datei definiert die übergeordneten Attribute des Features, beispielsweise seine ID und seinen benutzerfreundlichen Titel.
Neben der Datei „feature.xml“ enthält ein Feature in der Regel eine oder mehrere zusätzliche XML-Dateien (z. B. elements.xml), die die eigentlichen Elemente definieren, aus denen das Feature besteht. Das Verzeichnis kann auch andere Arten von Dateien, beispielsweise für Listendefinitionen und Seitenvorlagen, sowie Ressourcen wie Bilder, Cascading Stylesheets und JavaScript enthalten. Das Featureverzeichnis in meinem Beispiel enthält eine zusätzliche Datei, die als Dokumentvorlage für eine Dokumentbibliothek dient.
Eine gute Möglichkeit, Sie mit Features vertraut zu machen, besteht in der Betrachtung des standardmäßigen Featuresatzes, der Bestandteil der WSS-Standardinstallation ist. Abbildung 1 zeigt ein Beispiel für das Verzeichnis FEATURES nach der Installation von WSS. Wie Sie sehen können, verfügt jedes Feature über ein eigenes Verzeichnis. Wenn MOSS installiert ist, sieht das Verzeichnis FEATURES ganz anders aus, da MOSS mehr als 100 Features beinhaltet.
Abbildung 1 Standardmäßiges FEATURES-Verzeichnis (Klicken Sie zum Vergrößern auf das Bild)
Nachdem Sie das Verzeichnis mit allen Dateien, aus denen Ihr Feature besteht, erstellt haben, müssen Sie es anschließend mit WSS auf Farmebene installieren. Nachdem ein Feature mit WSS installiert wurde, kann es im Kontext einer Website oder Websitesammlung mithilfe einer Administrationsseite aktiviert werden, auf die über die Seite „Websiteeinstellungen“ zugegriffen werden kann.
Der Download zu diesem Artikel enthält ein Visual Studio®-Projekt namens „OfficeSpaceFeature“, das ein Feature mit dem gleichen Namen beinhaltet. Abbildung 2 zeigt eine Ansicht des Projektmappen-Explorers, um Ihnen eine Vorstellung davon zu geben, welche Arten von Dateien an der Erstellung eines Visual Studio-Projekts zur Entwicklung eines benutzerdefinierten Features für WSS oder MOSS beteiligt sind. Ich habe das Beispiel für diesen Artikel als Visual Basic-DLL-Projekt erstellt. Sie können stattdessen natürlich auch ein in C# geschriebenes DLL-Projekt verwenden, wenn Sie dies bevorzugen. Der verwaltete Code in der Assembly-DLL muss mit einem starken Namen kompiliert und im globalen Assemblycache (GAC) installiert werden, damit er für die Ereignishandler des Features verwendet werden kann.
Abbildung 2 OfficeSpaceFeature 

Struktur eines Features
Bevor ich näher auf die Datei „feature.xml“ eingehe, möchte ich Sie auf Folgendes hinweisen: Die Dateien für dieses Feature müssen in einem eigenen speziellen Verzeichnis im WSS-Systemverzeichnis FEATURES bereitgestellt werden. Das Verzeichnis FEATURES befindet sich in einem anderen WSS-Systemverzeichnis namens TEMPLATE (siehe Abbildung 1). Angesichts der Anforderungen an die Featurebereitstellung ist es sinnvoll, eine parallele Hierarchie von Ordnern innerhalb eines Visual Studio-Projekts zu erstellen, das zum Entwickeln eines WSS-Features verwendet wird. Dadurch können die Featuredateien während der Entwicklungsarbeit einfacher an den richtigen Speicherort kopiert und anschließend getestet werden.
Fügen Sie zunächst dem Stammverzeichnis des aktuellen Projekts einen Ordner namens TEMPLATE hinzu. Erstellen Sie dann im Verzeichnis TEMPLATE ein weiteres Verzeichnis namens FEATURES. Erstellen Sie zuletzt im Verzeichnis FEATURES ein weiteres Verzeichnis mit dem Namen des Featureprojekts. In diesem Fall lautet der Name des Projekts und des Verzeichnisses „OfficeSpaceFeature“ (siehe Abbildung 2).
Beschäftigen wir uns jetzt mit dem CAML-Inhalt in der Datei „features.xml“. Die Datei „feature.xml“ dient als Featuremanifest, in dem Sie die Informationen angeben, die die übergeordneten Attribute des Features selbst definieren. Die Datei „feature.xml“ für das Beispielfeature ist in Abbildung 3 dargestellt.
<?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>
Wie Sie sehen können, wird ein Feature mithilfe eines Feature-Elements definiert, das mehrere Attribute enthält, z. B. Id, Title, Description, Version, Scope, Hidden und ImageUrl. Sie müssen eine neue GUID für das Attribut „Id“ erstellen, damit das Feature eindeutig identifiziert werden kann. Sie erstellen die Attribute „Title“ und „Description“ des Features mithilfe von benutzerfreundlichem Text. Diese Attribute werden den Benutzern auf den Administrationsseiten von WSS, die zum Aktivieren und Deaktivieren von Features verwendet werden, direkt angezeigt.
Das Attribut „Scope“ definiert den Kontext, in dem das Feature aktiviert und deaktiviert werden kann. Das Feature, das ich erstelle, besitzt einen Bereich, der „Web“ entspricht. Dies bedeutet, dass es im Kontext einer Website aktiviert und deaktiviert werden kann. Wenn Sie „Scope“ stattdessen den Wert „Site“ zuweisen, kann Ihr Feature innerhalb des Bereichs einer Websitesammlung aktiviert und deaktiviert werden. Die beiden anderen möglichen Bereiche für die Definition eines Features sind „WebApplication“ und „Farm“.
Wie Sie sehen können, weist das Attribut „Hidden“ den Wert FALSE auf. Dies bedeutet, dass das Feature nach der Installation in der Farm von Benutzern angezeigt werden kann, die es aktivieren möchten. Wenn Sie beim Erstellen eines Features den Wert des Attributs „Hidden“ auf TRUE setzen, wird das Feature in der Liste der verfügbaren Features, die den Benutzern angezeigt wird, ausgeblendet. Ausgeblendete Features müssen über die Befehlszeile, benutzerdefinierten Code oder eine Aktivierungsabhängigkeit von einem anderen Feature aktiviert werden.
Möglicherweise haben Sie bemerkt, dass das Attribut „ImageUrl“ einen Wert aufweist, der auf eines der Bilder verweist, die Bestandteil der Standardinstallation von WSS sind. Dieses Bild wird auf der Benutzeroberfläche neben dem Feature angezeigt.
Der letzte Teil der in Abbildung 3 gezeigten Datei „feature.xml“ ist das Element „Element­Manifests“. Dieses Element enthält innere ElementManifest-Elemente, die auf andere XML-Dateien verweisen, in denen Sie die Elemente definieren, aus denen das Feature besteht. In diesem Fall ist ein einzelnes ElementManifest-Element vorhanden, in dem mithilfe des Attributs „location“ auf eine Datei namens „element.xml“ verwiesen wird.
Beachten Sie, dass Sie beim Hinzufügen und Ändern von XML in CAML-basierten Dateien wie feature.xml und elements.xml Unterstützung für von XML-Schemas gesteuerte IntelliSense®-Funktionen hinzufügen sollten. Im Verzeichnis TEMPLATE ist ein Verzeichnis namens XML vorhanden, das mehrere XML-Schemas enthält, einschließlich des Schemas „wss.xsd“. Wenn Sie diese Schemadatei Featuredateien wie feature.xml und elements.xml zuordnen, stellt Visual Studio IntelliSense bereit, wodurch die Entwicklung eines benutzerdefinierten Features stark vereinfacht wird.
Betrachten wir nun den Inhalt der Datei „element.xml“. Angenommen, Sie möchten bei jeder Aktivierung des Features eine Dokumentbibliothek instanziieren. Sie können eine Datei namens „elements.xml“ wie die in Abbildung 4 erstellen.
<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>
Das erste Element in der Abbildung, ein ListInstance-Element, wird verwendet, um eine Instanz einer Liste oder einer Dokumentbibliothek zu erstellen. Beachten Sie, dass ListInstance ein FeatureId- und ein TemplateType-Element enthält, um auf einen bestimmten Listentyp und auf die ID für das Feature, in dem dieser Listentyp definiert ist, zu verweisen. In diesem Fall verwende ich den Standardtyp für WSS-Dokumentbibliotheken mit dem TemplateType-Bezeichner 101, um eine neue Dokumentbibliothek mit dem Titel „Customer Letters“ zu erstellen. Unter dem ListInstance-Element befindet sich zudem ein Module-Element, das ein inneres File-Element enthält. Dieses File-Element wird verwendet, um eine Dokumentvorlage für die Dokumentbibliothek bereitzustellen. Genauer gesagt, erhält WSS von diesem File-Element die Anweisungen für das Kopieren einer Datei namens „LetterTemplate.docx“ aus dem Featureverzeichnis in die WSS-Site. Dadurch wird sie für die Benutzer zugänglich.
Obwohl die deklarative Logik in elements.xml in der Regel für das Erstellen von Elementen innerhalb einer WSS-Site ausreicht, muss sie häufig von programmatischer Logik begleitet werden. Für mein Beispiel habe ich eine neue Dokumentbibliothek erstellt und eine Datei bereitgestellt, die als Dokumentvorlage dienen soll. Um die Dokumentvorlage der Dokumentbibliothek zuzuordnen, muss ich jedoch zusätzlichen Code bereitstellen, der auf der Grundlage des WSS-Objektmodells programmiert wird.
Sie sehen, dass das Feature-Element in der Datei „feature.xml“ zwei Attribute enthält: ReceiverAssembly und ReceiverClass. Diese Attribute werden konfiguriert, um auf eine als Featureempfänger bezeichnete verwaltete Klasse zu verweisen, die Ereignishandler bereitstellt. Die Ereignishandler innerhalb einer Featureempfängerklasse werden bei der Installation oder Aktivierung eines Features sowie bei der Deinstallation oder Deaktivierung eines Features ausgelöst. Sie erstellen einen Featureempfänger durch Erstellen einer Klasse, die von der SPFeatureReceiver-Klasse erbt (siehe Abbildung 5).
Imports 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
Für das Beispiel stelle ich nur im Feature-Activated-Ereignishandler Code bereit. Dieser Code verwendet das WSS-Objektmodell für die Zuordnung der Dokumentvorlage zur Dokumentbibliothek „Customer Letters“. Im Ereignishandler erfolgt dies durch Erhalt eines SPWeb-Verweises auf die aktuelle Website und dann eines SPDocumentLibrary-Verweises auf die Zieldokumentbibliothek. Dadurch kann die DocumentTemplateUrl-Eigenschaft folgendermaßen geändert und diese Änderung mit einem Aufruf der Update-Methode gespeichert werden:
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

Bereitstellen und Aktivieren des Features
Nachdem ich nun die Dateien „feature.xml“ und „elements.xml“ erstellt habe, möchte ich mein Feature zu Testzwecken installieren. Die Installation des Features umfasst vier Schritte. Zuerst muss ich die Assemblydatei „OfficeSpaceFeature.dll“ im globalen Assemblycache (GAC) installieren. Dann muss ich das Verzeichnis „OfficeSpaceFeature“ in das WSS-Systemverzeichnis FEATURES kopieren. Der nächste Schritt besteht in der Ausführung von Stsadm.exe, um das Feature mit WSS zu installieren. Zuletzt muss ich das Feature im Kontext einer WSS-Site aktivieren.
Ich kann die ersten drei Schritte automatisieren, indem ich eine Batchdatei namens „install.bat“ im Stammverzeichnis meines OfficeSpaceFeature-Projekts erstelle und die in Abbildung 6 gezeigten Befehlszeilenanweisungen hinzufüge. Ich könnte auch den vierten Schritt automatisieren, indem ich den ActivateFeature-Vorgang mit dem Dienstprogramm „Stsadm.exe“ ausführe. Ich habe mich bei meinem Beispiel jedoch dagegen entschieden, weil ich Ihnen den Prozess zur manuellen Aktivierung des Features, wie ihn die Benutzer über die WSS-Benutzeroberfläche durchführen werden, zeigen möchte.
@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
Nach dem Hinzufügen von Anweisungen zur Datei „install.bat“ konfiguriere ich Visual Studio so, dass das Programm bei jeder Neuerstellung des OfficeSpaceFeature-Projekts ausgeführt wird. Hierzu navigiere ich in den Projekteigenschaften zur Registerkarte „Buildereignisse“ und füge die folgenden Befehlszeilenanweisungen für das Postbuildereignis hinzu:
cd $(ProjectDir)
Install.bat
Die erste Zeile ist erforderlich, um das aktuelle Verzeichnis in das Projektverzeichnis zu ändern. Durch die zweite Zeile wird die Batchdatei ausgeführt, um die Featuredateien in das richtige Verzeichnis zu kopieren und anschließend das Feature mit dem InstallFeature-Vorgang des Befehlszeilenprogramms „Stsadm.exe“ zu installieren.
Nach der ordnungsgemäßen Installation des Features kann ich es nun im Kontext einer Website aktivieren. Sie können diesen Vorgang innerhalb jeder Website in einer WSS- oder MOSS-Farm durch Navigation zur Seite „Websiteeinstellungen“ durchführen. Klicken Sie im Abschnitt „Websiteverwaltung“ einfach auf den Link mit dem Titel „Websitefeatures“. Dadurch sollten Sie auf eine ähnliche Seite wie die in Abbildung 7 gelangen. Wenn Sie in einer Farm arbeiten, in der MOSS installiert ist, werden viel mehr Features angezeigt als bei der Arbeit in einer Farm, in der nur WSS installiert ist.
Abbildung 7 Aktivieren und Deaktivieren von Websitefeatures (Klicken Sie zum Vergrößern auf das Bild)
Der Titel und die Beschreibung von OfficeSpaceFeature werden auf der Seite „Websitefeatures“ angezeigt, sodass ich das Feature leicht finden kann. Anschließend klicke ich auf die Schaltfläche „Aktivieren“. Jetzt sollten alle Elemente, die in elements.xml mit deklarativer Logik definiert wurden, innerhalb der aktuellen Website bereitgestellt werden. WSS lädt dann die Empfängerassembly aus dem GAC, erstellt eine Instanz der Empfängerklasse und führt die FeatureActivated-Methode der Empfängerklasse aus.
Mein Beispiel ist recht einfach. Wie Sie sich jedoch vielleicht vorstellen können, können Sie in FeatureActivated eine viel komplexere Mischung aus deklarativen CAML-Elementen und WSS-Objektmodellcode bereitstellen.

Erweitern des Features
Bei Betrachtung der Datei „elements.xml“ werden Sie bemerken, dass sie ein zweites ListInstance-Element enthält. Es wird verwendet, um mithilfe des integrierten Listentyps „WSS Contacts“ eine Liste mit dem Titel „Customers“ zu erstellen. Dieses ListInstance-Element zeigt auch, wie der Liste einige Standardelemente hinzugefügt werden, um bestimmte Beispielkundendaten bereitzustellen.
Ich habe Ihnen gezeigt, wie Sie deklarative CAML-Logik zum Erstellen von Listen und Dokumentbibliotheken verwenden können. An dieser Stelle möchte ich jetzt darauf hinweisen, dass Sie auch mithilfe von benutzerdefiniertem Code im Featureaktivierungsereignis, der auf der Grundlage des WSS-Objektmodells programmiert wird, eine Liste oder Dokumentbibliothek erstellen können.
Das Beispielfeature enthält Code im FeatureActivated-Ereignishandler, um eine weitere Liste mit dem Titel „Letter Templates“ anhand des WSS-Standardtyps „Custom List“ zu erstellen. Wenn Sie eine neue Liste mithilfe des WSS-Standardtyps „Custom List“ erstellen, enthält die Liste automatisch ein Feld mit dem Namen „Title“. Durch den Beispielcode wird eine zweite Spalte namens „Body“ erstellt. Zudem wird das WSS-Objektmodell zum Hinzufügen einiger Listenelemente verwendet, die die Daten bereitstellen, die als Vorlagen für das Erstellen von Briefen an Kunden dienen. Der Code hierfür ist in Abbildung 8 dargestellt.
Dim 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()

Benutzerdefinierte Anwendungsseiten
Das Verständnis des Featurekonzepts und der Verwendung von Features ist wichtig. Es gibt jedoch noch eine zweite wesentliche Grundlage für das Entwerfen und Entwickeln von Lösungen für WSS und MOSS. Die WSS-Architektur unterstützt einen speziellen Seitentyp, der als Anwendungsseite bezeichnet wird. Die Standardseite „Websiteeinstellungen“ (settings.aspx) ist ein gutes Beispiel für eine Anwendungsseite. Die Seite „settings.aspx“ wird pro Front-End-Webserver einmal bereitgestellt, und dennoch kann von jeder Website innerhalb einer WSS-Farm auf sie zugegriffen werden.
Anwendungsseiten werden als physische Dateien im Dateisystem des Front-End-Webservers in einem Verzeichnis mit dem folgenden Pfad bereitgestellt:
%PROGRAMFILES%\common files\microsoft shared
   \web server extensions\12\TEMPLATE\LAYOUTS
WSS ordnet bei jeder Bereitstellung einer neuen Webanwendung das physische Verzeichnis LAYOUTS dem virtuellen Verzeichnis „_layouts“ zu. Mithilfe dieses Zuordnungsschemas und zusätzlicher Verarbeitungslogik macht die WSS-Laufzeit jede Anwendungsseite im Kontext beliebiger Websites in der Farm zugänglich. Angenommen, dass über die folgenden drei URLs auf drei verschiedene Websites in einer WSS-Farm zugegriffen werden kann:
http://Litwareinc.com
http://Litwareinc.com/sites/Vendors
http://Litwareinc.com:1001/sites/Accounting
Auf eine Anwendungsseite kann zugegriffen werden, indem ihr relativer Pfad im Verzeichnis „_layouts“ am Ende der URL einer Website hinzugefügt wird. Sie können beispielsweise mithilfe einer der folgenden URLs auf die Seite „Websiteeinstellungen“ zugreifen:
http://Litwareinc.com/_layouts/settings.aspx
http://Litwareinc.com/sites/Vendors/_layouts/settings.aspx
http://Litwareinc.com:1001/sites/Accounting/_layouts/settings.aspx
Da nur eine Version einer Anwendungsseite auf der Farmebene vorhanden ist, kann sie in einer einzigen DLL kompiliert und einmal in den Speicher geladen werden. Sie müssen sich nie darüber Gedanken machen, dass verschiedene Versionen einer Anwendungsseite für verschiedene Websites vorhanden sein könnten. Darüber hinaus unterliegen Anwendungsseiten keinen Angriffen durch Benutzer, die zum Anpassen der Seiten von Websites berechtigt sind. Daher verbietet WSS nicht, dass Anwendungsseiten Inlinecode enthalten.
Anwendungsseiten werden vom WSS-Team häufig verwendet, um einen Großteil der Standardfunktionalität für das Bereitstellen und Verwalten von Websites und der darin enthaltenen Elemente zur Verfügung zu stellen. WSS unterstützt auch benutzerdefinierte Anwendungsseiten für benutzerdefinierte Geschäftslösungen. Das Beispiel im Artikel dieses Monats enthält eine benutzerdefinierte Anwendungsseite namens „LetterGenerator.aspx“, die wie jede andere Anwendungsseite im Verzeichnis LAYOUTS bereitgestellt wird.
Beachten Sie, dass LetterGenerator.aspx nicht direkt im Verzeichnis LAYOUTS, sondern in einem Verzeichnis namens „OfficeSpace“ bereitgestellt wird, das sich im Verzeichnis LAYOUTS befindet. Es empfiehlt sich, ein eigenes Verzeichnis im Verzeichnis LAYOUTS zum Hosten benutzerdefinierter Anwendungsseiten zu erstellen, um potenzielle Namenskonflikte zu vermeiden.
Eine Anwendungsseite ist ein spezieller Typ einer ASP.NET-Seite, die in der Regel so erstellt wird, dass sie von einer Basisklasse namens „LayoutsPageBase“ erbt und mit der vom WSS-Team erstellten Standardmasterseite „application.master“ verknüpft ist. Abbildung 9 zeigt ein Beispiel für die klassische benutzerdefinierte Anwendungsseite „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>
Sie sehen, dass Sie eine Anwendungsseite erstellen können, die standardmäßige ASP.NET-Steuerelemente sowie Code in standardmäßigen ASP.NET-Seitenüberschreibungen wie OnLoad enthält. Sie können auch Assemblyverweise hinzufügen. Wenn Sie Microsoft.SharePoint.dll einen Verweis hinzufügen, können Sie anschließend die Programmierung auf Grundlage der aktuellen Websitesammlung und der aktuellen Website vornehmen, indem Sie über die SPContext-Klasse einen Verweis erhalten (siehe Abbildung 9).
Nachdem Sie einer Lösung eine benutzerdefinierte Anwendungsseite hinzugefügt haben, müssen Sie eine Methode bereitstellen, mit der die Benutzer zu dieser Seite navigieren können. Durch Hinzufügen eines CustomAction-Elements zu einem Feature können Sie einen Link oder ein Menüelement zur Verfügung stellen. Es folgt ein Beispiel dafür, wie das CustomAction-Element in OfficeSpaceFeature verwendet wird, um der Dropdownliste „Websiteaktionen“ ein Menüelement hinzuzufügen:
<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>
Dieses CustomAction-Element fügt das benutzerdefinierte Menüelement dem standardmäßigen Menü „Websiteaktionen“ hinzu. Das UrlAction-Element im CustomAction-Element stellt das Url-Attribut mit einem relativen Pfad zu meiner benutzerdefinierten Anwendungsseite bereit. Der dem Url-Attribut zugewiesene Zeichenfolgenwert verfügt in Form von ~site über ein dynamisches Token. Dieses wird von WSS zur Laufzeit durch den tatsächlichen Pfad zur aktuellen Website ersetzt.
Wenn Benutzer das benutzerdefinierte Menüelement auswählen, werden sie zur benutzerdefinierten Anwendungsseite LetterGenerator.aspx umgeleitet, die die in Abbildung 10 dargestellte Benutzeroberfläche anzeigt. Die OnLoad-Methode dieser Seite enthält Code, der die beiden Listenfelder mit dem gewünschten Kunden- und Brieftyp auffüllt. Dabei wird das WSS-Objektmodell zum Abrufen von Daten aus den zwei Listen verwendet, die bei der Featureaktivierung erstellt wurden. Es sind auch zwei Befehlsschaltflächen vorhanden, die zwei verschiedene Methoden dafür bieten, Briefe an Kunden mit dem Code, den ich in meinem vorigen Office Space-Artikel beschrieben habe, als .docx-Dateien zu erstellen.
Abbildung 10 Benutzerdefinierte Anwendungsseite (Klicken Sie zum Vergrößern auf das Bild)
Wenn der Benutzer auf eine der Befehlsschaltflächen klickt, führt der Ereignishandler Code aus, um mit den Office Open-Dateiformaten einen Brief zu generieren. Dieser Code ist nahezu mit dem Code identisch, den ich in meinem vorigen Artikel beschrieben habe. Der einzige Unterschied besteht in dem Code, der verwendet wird, um die Datei zu benennen und sie in der WSS-Dokumentbibliothek mit dem Titel „Customer Letters“ zu speichern.
Dieses Beispiel zeigt, wie die Erstellung von Briefen an Kunden mit den Office Open XML-Dateiformaten automatisiert werden kann, und es demonstriert die Synergie, die zwischen WSS und diesen Dateiformaten existiert.
Nachdem Sie eine neue .docx-Datei erstellt haben, benötigen Sie einen Speicherort für die Datei. WSS bietet einen idealen Speicherort für Dokumente, an dem sie mit Versionsanmerkungen versehen werden können und für ein Team zugänglich sind, das in einer auf Zusammenarbeit ausgerichteten Umgebung arbeitet. Abbildung 11 zeigt die Dokumentbibliothek „Customer Letters“ auf einer Website, für die OfficeSpaceFeature aktiviert ist.
Abbildung 11 Dokumentbibliothek „Customer Letters“ (Klicken Sie zum Vergrößern auf das Bild)

Zusammenfassung
Im Artikel dieses Monats werden Ihnen Features und benutzerdefinierte Anwendungsseiten vorgestellt – zwei grundlegende Bausteine für das Entwerfen und Implementieren von Lösungen für WSS und MOSS. Sie sollten jetzt eine gute Vorstellung davon haben, wie Sie mit der Entwicklung und dem Testen beginnen können. Im nächsten Artikel der Office Space-Reihe werde ich erläutern, wie Sie eine Lösung wie die, die ich gerade beschrieben habe, für die Bereitstellung in einer Produktionsumgebung verpacken können.

Senden Sie Fragen und Kommentare für Ted Pattison in englischer Sprache an instinct@microsoft.com.


Ted Pattison ist Autor, Schulungsleiter und SharePoint-MVP und lebt in Tampa, Florida, USA. Ted hat gerade sein Buch Inside Windows SharePoint Services 3.0 für Microsoft Press beendet. Er bietet zudem über sein Unternehmen Ted Pattison Group Fortgeschrittenenschulungen zu SharePoint für professionelle Entwickler an.

Page view tracker