Exportieren (0) Drucken
Alle erweitern

Entdecken Sie bedeutende Verbesserungen für Entwickler in SharePoint Services

Veröffentlicht: 11. Sep 2006
Von Ted Pattison

Dieser Artikel basiert auf einer Vorabversion von Windows SharePoint Services. Änderungen an allen Informationen in diesem Artikel sind vorbehalten.

Die nächste Hauptversion von Microsoft Office SharePoint Server (MOSS) mit Windows® SharePoint® Services (WSS) Version 3.0 wird sehr bald herausgegeben. Wie bei den vorherigen Versionen bietet WSS fertige Zusammenarbeitsfeatures, die es Benutzern erleichtern, Websites mit gemeinsamen Elementen, wie z. B. Kalendern, Kontaktlisten und Dokumentbibliotheken, zu entwerfen und zu erstellen. Doch WSS ist weit mehr als nur ein Tool für die Zusammenarbeit für Endbenutzer. Es ist eine vollständige Entwicklungsplattform, die den Wert von ASP.NET enorm steigert.

WSS 3.0 ist ein Add-On für Windows Server™ 2003. Im Kern funktioniert WSS wie ein skalierbares Sitebereitstellungsmodul, das das Erstellen und Verwalten von hunderten bzw. tausenden von Websites erleichtert und diese für zehntausende von Benutzern zugänglich macht. Die Skalierbarkeit von WSS wird durch eine Architektur erreicht, die mit einer Webfarmumgebung im Hinterkopf entworfen wurde. Diese Architektur basiert auf statusfreien Front-End-Webservern, die Inhalte und andere sitebezogene Daten in SQL Server™ speichern.

Die Wertsteigerung der ASP.NET 2.0-Entwicklungsplattform durch WSS ist das Ergebnis des Erweiterungsmodells, das die Bereitstellung und Speicherung von Seiten, Listen und Dokumentbibliotheken erleichtert. Die Bereitstellung kann entweder durch benutzerdefinierten Code oder Benutzeraktionen in der browserbasierten Benutzeroberfläche ermöglicht werden. Hinter den Kulissen findet WSS automatisch heraus, wo und wie die Inhalte gespeichert werden. Außerdem werden die Benutzeroberflächenelemente bereitgestellt, mit denen Benutzer Inhalte hinzufügen, anzeigen und ändern können.

Dieser Artikel wird sich auf die wichtigsten Verbesserungen für Entwickler in Version 3 konzentrieren sowie auf die entsprechenden Änderungen in der Terminologie. Weitere Informationen finden Sie in „SharePoint: Use Windows SharePoint Services as a Platform for Building Collaborative Applications“ in der Ausgabe des MSDN®-Magazins vom Juli 2004.

Denken Sie daran, dass die Nachforschungen und Codebeispiele für diesen Artikel auf der Version Beta 1 von WSS basieren. Einige der Begriffe und Codes können in der herausgegebenen Version verändert sein.

Auf dieser Seite

 Integration mit ASP.NET 2.0
 Seitenvorlagen
 Mit Masterseiten arbeiten
 Webparts in WSS
 Entwerfen von benutzerdefinierten Webparts
 Verbesserungen bei der Inhaltsspeicherung
 Ereignishandler
 Workflows in WSS
 Sitedefinitionen, Features und Lösungen
 Internetsicherheitsfeatures
 Schlussbemerkung
 Der Autor

Integration mit ASP.NET 2.0

Die Bereitstellung von WSS 3.0 beginnt mit einer IIS-Website. Bevor Sie Ihre erste WSS-Site erstellen können, müssen Sie eine administrative Prozedur ausführen, durch die die WSS-Funktionalität auf eine oder mehrere IIS-Websites ausgedehnt wird. In WSS 2.0 wurde mit dem Begriff „virtueller Server“ eine IIS-Website beschrieben, die um SharePoint-Funktionalität erweitert worden war. Um Verwechslungen mit einem anderen Microsoft-Produkt desselben Namens zu vermeiden, wird eine um WSS-Funktionalität erweiterte IIS-Website in der WSS 3.0-Dokumentation jetzt als Webanwendung bezeichnet.

WSS 2.0 wurde in eine ISAPI-Filter-DLL in IIS 6.0 und ASP.NET 1.1 integriert, wodurch IIS Anforderungen vor ASP.NET an WSS weiterleitete. Diese Weiterleitung konnte in bestimmten Situationen problematisch sein, da WSS die Kontrolle über eine eingehende HTTP-Anforderung übernahm, bevor diese im ASP.NET-Kontext korrekt initialisiert werden konnte.

Die Integration von WSS in ASP.NET wurde in Version 3 vollständig neu entworfen. Zunächst einmal baut WSS 3.0 auf ASP.NET 2.0 auf, das gegenüber ASP.NET 1.1 deutliche Verbesserungen bietet. Außerdem wurde die Routinginfrastruktur verbessert, indem der ISAPI-Filter entfernt und ein HttpModule und ein HttpHandler hinzugefügt wurden, die mit standardmäßigen web.config-Einträgen in ASP.NET registriert sind. Das bedeutet, dass eingehende HTTP-Anforderungen immer in die ASP.NET-Laufzeitumgebung eintreten und vollständig im ASP.NET-Kontext initialisiert werden, bevor sie an den Code weitergeleitet werden, der die WSS-spezifische Verarbeitung durchführt.

Wenn Sie eine IIS-Website zu einer Webanwendung erweitern, fügt WSS 3.0 der IIS-Metabase einen Anwendungsplatzhalter hinzu. Durch diese Zuordnung werden alle eingehenden HTTP-Anforderungen ungeachtet des Dateityps (.pdf, .doc, .docx und so weiter) an die ASP.NET-Laufzeitumgebung weitergeleitet. ASP.NET leitet die Anforderung dann zur Verarbeitung an WSS weiter.

Die neue Architektur behebt außerdem Unzulänglichkeiten, die mit der Analyse und Kompilierung von ASPX-Seiten zusammenhängen. Der von ASP.NET 1.1 verwendete ASPX-Seitenparser kann nur Seiten verarbeiten, die sich im lokalen Dateisystem befinden. Die WSS-Architektur jedoch speichert ASPX-Seiten in einer SQL Server-Datenbank, sodass der Seitenparser in ASP.NET 1.1 nicht genutzt werden konnte. Und leider unterstützt der stattdessen entwickelte SharePoint-Parser viele der nützlichen Features des ASP.NET-Seitenparsers nicht.

Doch ASP.NET 2.0 stellt einen neuen austauschbaren Komponententyp vor, den Anbieter für einen virtuellen Pfad. Der Gedanke ist, dass ein Entwickler eine benutzerdefinierte Komponente schreiben kann, die ASPX-Seiten (oder beliebige andere, von ASP.NET verarbeitete Inhalte) von einem beliebigen Speicherort abruft, einschließlich einer Datenbank wie z. B. SQL Server. Sobald ein benutzerdefinierter Anbieter für einen virtuellen Pfad eine ASPX-Seite abruft, kann er dann die Seite an ASP.NET übergeben, das die erforderliche Analyse und Kompilierung durchführt. Mit der separaten Komponente PageParserFilter kann SharePoint steuern, wie Seiten analysiert und kompiliert werden und welche Elemente auf diesen Seiten ausgeführt werden.

WSS 3.0 enthält seinen eigenen Anbieter für einen virtuellen Pfad, den SPVirtualPathProvider. Dieser ist in Abbildung 1 dargestellt. Wie Sie sehen können, kann SPVirtualPathProvider ASPX-Seiten von SQL Server abrufen und diese dann an den von ASP.NET 2.0 bereitgestellten ASPX-Parser übergeben. Hinsichtlich der Seitenanalyse mangelt es WSS 3.0 also nicht wie der Vorgängerversion von WSS an Features.

Abbildung 1: Anbieter für einen benutzerdefinierten virtuellen Pfad und ASP.NET 2.0
Abbildung 1:   Anbieter für einen benutzerdefinierten virtuellen Pfad und ASP.NET 2.0

Seitenvorlagen

Die Begriffe „Ghosting“ und „Unghosting“ werden häufig in Zusammenhang mit den ASPX-Seiten einer WSS 2.0-Site verwendet. Beim Seitenghosting kann ein Front-End-Webserver eine ASPX-Seitenvorlage in seinem lokalen Dateisystem speichern und diese Vorlage über viele verschiedene Sites hinweg freigeben. Das Seitenghosting bietet Leistungsvorteile, da WSS mit einer Seitenvorlage, die im lokalen Dateisystem gespeichert ist und nur einmal in den Speicher geladen wird, Seiten für tausende von Sites zur Verfügung stellen kann.

WSS 2.0 unterstützte Benutzeränderungen an der Seitenvorlage mit Tools wie Microsoft® Office FrontPage® 2003. Wenn ein Benutzer eine Seitenvorlage ändert und die Änderungen speichert, wird für diese bestimmte Site eine benutzerdefinierte Version der Seite in SQL Server gespeichert. Dies wird häufig als Unghosting einer Seite bezeichnet.

WSS 3.0 unterstützt nach wie vor Seitenvorlagen, die auf dem Webserver gespeichert sind, außerdem benutzerdefinierte Versionen, die in SQL Server gespeichert sind. In der Dokumentation werden die Begriffe Ghosting und Unghosting jedoch nicht mehr verwendet. Jetzt wird mit dem Begriff „nicht benutzerdefinierte Seite“ eine Seitenvorlage beschrieben, die direkt aus dem lokalen Dateisystem des Webservers verwendet wird. Mit einer „benutzerdefinierten Seite“ ist eine geänderte Version der Seitenvorlage gemeint, die für eine bestimmte Site in die Inhaltsdatenbank geschrieben wurde.

Microsoft Office FrontPage 2003 wurde umbenannt in Office SharePoint Designer 2007, doch das Zielpublikum sind weiterhin eher Benutzer als Entwickler. Dennoch ist es ein nützliches Werkzeug für WSS-Entwickler. SharePoint Designer bietet sowohl einen Code-Editor als auch einen WYSIWYG-Designer zum Anpassen von ASPX- und MASTER-Seiten in WSS-Sites, und Sie können neue Seiten in einer Site erstellen, die keine entsprechende Seitenvorlage auf dem Webserver hat. Außerdem können Sie Listen und Dokumentbibliotheken erstellen. Es gibt sogar einen neuen Assistenten zum Erstellen von benutzerdefinierten Workflows in einer WSS-Site. Dies wird später ausführlicher erläutert.

Mit Masterseiten arbeiten

Eine der aufwändigsten Aufgaben beim Anpassen und Branding von Sites in WSS 2.0 war das Erstellen eines konsistenten Erscheinungsbildes über mehrere Seiten hinweg, da ASP.NET 1.1 keine geeigneten Techniken für die Erstellung von Seitenvorlagen bietet. Daher kopierten viele Entwickler und Designer HTML-Layouts und fügten diese auf den einzelnen Seiten ein. Dadurch wird es sehr schwierig, eine Site anzupassen und zu verwalten, deren Layoutanforderungen von denen einer standardmäßigen WSS-Site abweichen.

Mit einem leistungsfähigen Feature zum Erstellen von Seitenvorlagen, den mit ASP.NET 2.0 eingeführten Masterseiten, wurde Abhilfe geschaffen. Eine Masterseite ist eine Vorlage, mit der Sie ein standardmäßiges Seitenlayout für eine gesamte Site mit Elementen wie z. B. einem Banner, Navigationssteuerelementen und weiteren Menüs erstellen können. Die mit einer Masterseite verknüpften Seiten werden Inhaltsseiten genannt.

Das Schlüsselkonzept ist, dass jede Inhaltsseite eine Verknüpfung zur Masterseite herstellt und das gemeinsam genutzte Layout abruft. Anschließend wird die Masterseite erweitert, indem benutzerdefinierte Inhalte in benannte Platzhalter eingefügt werden. Weitere Informationen zur Funktionsweise von Masterseiten in ASP.NET finden Sie in dem Artikel von Fritz Onion, „Master Pages: Master Your Site Design with Visual Inheritance and Page Templates“ in der Ausgabe des MSDN-Magazins vom Juni 2004.

WSS 3.0 wurde von Grund auf dafür entwickelt, sich die Infrastruktur von Masterseiten in ASP.NET 2.0 zunutze zu machen. Jede Site der Version 3 ist mit einem besonderen Katalog ausgestattet, dem Masterseitenkatalog. Dieser enthält eine Seite namens default.master. Auf dieser Seite ist ein gemeinsames Layout für die Homepage jeder Site (default.aspx) festgelegt, außerdem alle standardmäßigen WSS-Formularseiten, die mit Listen und Dokumentbibliotheken verknüpft sind (z. B. AllItems.aspx und NewItem.aspx). Das Masterseitenlayout beinhaltet Standardmenüs und Navigationssteuerelemente. In Abbildung 2 ist eine Beispielseite dargestellt, die auf dem von default.master vorgegebenen Standardlayout basiert.

Abbildung 2: Standardlayout von Seiten, die von default.master vorgegeben sind
Abbildung 2:   Standardlayout von Seiten, die von default.master vorgegeben sind

Die Definition von default.master umfasst eine Reihe von benannten Platzhaltern wie PlaceHolderPageTitle, PlaceHolderMain und PlaceHolderLeftNavigation. Dadurch wird es relativ einfach, eine neue benutzerdefinierte Inhaltsseite mit demselben Layout wie andere Seiten in einer Site zu erstellen. Sehen Sie sich die Einfachheit der Inhaltsseitendefinition an:

<%@ 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>

Die Inhaltsseitendefinition platziert lediglich ein winziges Fragment HTML-Inhalt in PlaceHolderMain, doch wird dadurch ein typisches Seitenlayout mit Sitesymbolen, Menüs und Navigationsleisten, wie in Abbildung 3 dargestellt, geschaffen. Sobald Sie mit dem Standardsatz von Platzhaltern in default.master vertraut sind, können Sie WSS-Elemente wie Menüs und Navigationsleisten einfach durch Ihre eigenen ASP.NET-Steuerelemente ersetzen. Dies kann für die Seiten einer Site und einer ganzen Websitesammlung durchgeführt werden.

Abbildung 3: Benutzerdefinierte Inhaltsseite einer Masterseite
Abbildung 3:   Benutzerdefinierte Inhaltsseite einer Masterseite

Masterseiten und Inhaltsseiten werden wie die weiter oben erläuterten Seitenvorlagen und Anpassungsfunktionen gespeichert und geladen. Sowohl für die Masterseite als auch für die Inhaltsseiten sind Seitenvorlagen definiert, die sich im lokalen Dateisystem des Front-End-Webservers befinden. Jede Site verwendet zuerst nicht angepasste (ghosted) Versionen der Masterseitenvorlage und der Inhaltsseitenvorlagen. Wenn ein Benutzer eine dieser Seiten mit einem Tool wie SharePoint Designer anpasst und speichert, wird eine benutzerdefinierte (unghosted) Version in der SQL Server-Datenbank gespeichert.

Sie können die Masterseite für eine Site anpassen und die Inhaltsseiten unberührt lassen. Sie können aber auch eine oder mehrere Inhaltsseiten anpassen und die Masterseite in ihrem ursprünglichen Zustand belassen. Außerdem können Sie alle Änderungen rückgängig machen. Sowohl WSS als auch SharePoint Designer bieten einfache Menübefehle zum Verwerfen von Anpassungsänderungen aus der SQL Server-Datenbank und zum Wiederherstellen der ursprünglichen Seitenvorlage.

Sie haben vielleicht festgestellt, dass die zuvor gezeigte Inhaltsseite mit einer besonderen Syntax in der Form von ~masterurl/default.master mit der Masterseite verknüpft ist. Dies ist ein Verweis mit Token auf eine Masterseite, der programmgesteuert für die ganze Site geändert werden kann. Dazu erwerben Sie einen SPWeb-Verweis auf die aktuelle Site und aktualisieren anschließend die Eigenschaft MasterUrl (siehe Abbildung 4).

Beachten Sie, dass jede Site über einen eigenen Masterseitenkatalog mit einer Datei default.master und ihre eigene Eigenschaft MasterUrl verfügt. Das bedeutet, dass nicht alle Sites in einer Websitesammlung automatisch dieselbe Masterseite verwenden. Durch die Nutzung von Rekursion ist es jedoch recht einfach, einige Zeilen Code für das WSS 3.0-Objektmodell zu schreiben, um eine auf der höchsten Ebene stehende Site und alle untergeordneten Sites in einer Websitesammlung für die Verwendung derselben Masterseite zu synchronisieren. Dies ist in Abbildung 5 dargestellt.

Ein weiteres nützliches dynamisches Token für Masterseiten ist ~masterurl/custom.master. Dieses dynamische Token arbeitet mit der Eigenschaft CustomMasterUrl einer Site zusammen und bietet eine sekundäre Ziel-Masterseite, die programmgesteuert umgeleitet werden kann. Es gibt auch zwei statische Masterseitentokens, die entweder mit ~site oder ~sitecollection beginnen. Mit diesen statischen Tokens können Sie entweder vom Stammverzeichnis der aktuellen Site oder dem Stammverzeichnis der aktuellen Websitesammlung einen relativen Pfad zu einer Masterseite hartcodieren.

Webparts in WSS

Eine der beliebtesten Möglichkeiten für Entwickler zum Erweitern von WSS 2.0-Sites war das Erstellen benutzerdefinierter Webparts. Webparts sind sehr effektiv, da sie der Benutzeranpassung und -personalisierung neue Dimensionen verleihen. Größtenteils aufgrund der Beliebtheit der Webparts in WSS 2.0 hat Microsoft entschieden, ASP.NET 2.0 eine neue Infrastruktur von Webparts hinzuzufügen, die der in WSS ähnelt und sich doch davon unterscheidet.

Deshalb gibt es jetzt zwei verschiedene Webpartformate. Die älteren Webparts im WSS-Format sind von der Microsoft.SharePoint.dll abhängig und müssen von der WebPart-Basisklasse im Namespace Microsoft.SharePoint.WebPartPages erben. Die neueren Webparts im ASP.NET-Format sind von der System.Web.dll abhängig und müssen von einer anderen Basisklasse namens WebPart im Namespace System.Web.UI.WebControls.WebParts erben.

Es war ein wichtiges Entwicklungsziel für WSS 3.0, sowohl die Webparts im WSS-Format als auch die Webparts im ASP.NET-Format ausführen zu können. Dieses Ziel wurde erreicht, indem in WSS 3.0 die Unterstützung für Webparts auf der Infrastruktur für Webparts von ASP.NET aufgebaut und anschließend die Microsoft.SharePoint.dll geändert wurde, sodass für die WSS 2.0-Umgebung geschriebene Webparts im WSS-Format mit der Laufzeitumgebung von Version 3 kompatibel sind.

Um Webparts in einer ASP.NET 2.0-Anwendung ausführen zu können, müssen Sie eine ASPX-Site erstellen, die genau eine Instanz des Steuerelements WebPartManager und mindestens ein Steuerelement WebPartZone enthält. Der WebPartManager ist für die Serialisierung webpartbezogener Daten verantwortlich sowie für deren Speicherung und Abruf aus den Tabellen der ASP.NET-Dienstedatenbank.

Die ASPX-Seite, die als Webpartseite dient, kann EditorParts enthalten, mit denen Benutzer persistente Webparteigenschaften anpassen und personalisieren können. Webpartseiten können außerdem CatalogParts enthalten, mit denen Benutzer neue Webparts zu Zonen hinzufügen können. WSS 3.0 nimmt Ihnen das Hinzufügen von Catalog- und EditorParts ab, sodass ein Webseitendesigner diese Aufgaben nicht ausdrücklich ausführen muss. (Weitere Hintergrundinformationen zur Funktionsweise der Infrastruktur für Webparts in ASP.NET 2.0 finden Sie im Artikel „ASP.NET 2.0: Personalize Your Portal with User Controls and Custom Web Parts“.)

Die Infrastruktur für Webparts in WSS 3.0 baut auf einem Steuerelement namens SPWebPartManager auf, das von dem ASP.NET 2.0-Steuerelement WebPartManager abgeleitet ist. Das Steuerelement SPWebPartManager setzt das Standardverhalten des Steuerelements WebPartManager außer Kraft, um Webpartdaten in der WSS-Inhaltsdatenbank und nicht in der ASP.NET-Dienstedatenbank zu erhalten. In den meisten Fällen müssen Sie nicht direkt mit dem Steuerelement SPWebPartManager arbeiten, da die einzig erforderliche Instanz bereits in der Datei default.master definiert ist. Wenn Sie eine Inhaltsseite erstellen, die mit default.master verknüpft ist, ist das Steuerelement SPWebPartManager bereits vorhanden.

Weitere Steuerelemente, die in der Regel auf einer typischen Webpartseite in WSS 3.0 angezeigt werden, sind in Abbildung 6 dargestellt. Beachten Sie, dass Webpartzonen für eine Webpartseite in WSS 3.0 mit dem Steuerelement WebPartZone erstellt werden sollten, das in dem Namespace Microsoft.SharePoint.WebPartPages definiert ist, und nicht mit dem Standardsteuerelement WebPartZone aus ASP.NET 2.0.

Abbildung 6: Steuerelemente auf einer Webpartseite
Abbildung 6:   Steuerelemente auf einer Webpartseite

Instanzen des Steuerelements WebPartZone sind in der Regel auf Inhaltsseiten definiert. In Abbildung 7 sehen Sie ein einfaches Beispiel für das Erstellen einer Inhaltsseite, die in einer WSS 3.0-Site als Webpartseite fungieren soll. Wie Sie sehen, ist diese ASPX-Seite wie in dem früheren Beispiel mit default.master verknüpft. Die Seite erbt jedoch auch ausdrücklich von der Basisklasse WebPartPage und fügt zwei WebPartZone-Steuerelemente zu PlaceHolderMain hinzu.

Wenn Sie eine Webpartseite für eine standardmäßige ASP.NET 2.0-Anwendung erstellen, müssen Sie eine Logik hinzufügen, die mit dem Steuerelement WebPartManager interagiert, um den Webpartanzeigemodus zu verwalten. Im Allgemeinen müssen Sie auch ausdrücklich EditorParts und CatalogParts zu der Seite hinzufügen, zusammen mit dem HTML-Layout, in das sie eingesetzt werden. Glücklicherweise müssen Sie diese Aufgaben nicht erledigen, wenn Sie Inhaltsseiten für eine WSS 3.0-Site erstellen. Stattdessen erben Sie von der Klasse WebPartPage, die in dem Namespace Microsoft.SharePoint.WebPartPages definiert ist, und lassen sie hinter den Kulissen die ganze Arbeit machen.

Entwerfen von benutzerdefinierten Webparts

Der bevorzugte Ansatz zum Erstellen von Webparts für WSS 3.0-Sites ist das Erstellen von Webparts im ASP.NET-Format. Dies erfordert mindestens das Erstellen einer Klasse, die von der im Namespace System.Web.UI.WebControls.WebParts definierten Klasse WebPart erbt, und das Außerkraftsetzen der Methode RenderContents. Wenn Sie persistente Webparteigenschaften hinzufügen möchten, verwenden Sie dieselbe Technik wie in ASP.NET.

Die in Abbildung 8 dargestellte Webpartdefinition hat keine Abhängigkeiten von der Microsoft.SharePoint.dll, sodass sie entweder in einer standardmäßigen ASP.NET-Anwendung oder einer WSS 3.0-Site verwendet werden kann. In vielen Fällen jedoch werden Sie einen Verweis auf die Microsoft.SharePoint.dll hinzufügen wollen, sodass der Code hinter Ihren Webparts auch zum Programmieren für das WSS 3.0-Objektmodell verwendet werden kann.

WSS 3.0 wurde außerdem für die Unterstützung von Webparts entwickelt, die für die Umgebung der Version 2 erstellt wurden. Diese älteren WSS-Webparts erben von der Basisklasse WebPart in der Microsoft.SharePoint.dll, die in dem Namespace Microsoft.SharePoint.WebPartPages definiert ist.

Die Klasse WebPart in der älteren Version der Microsoft.SharePoint.dll wurde entworfen, um wie in Abbildung 9 dargestellt von der ASP.NET-Steuerelementklasse zu erben. Sie können jedoch auch sehen, dass die Klasse WebPart in der neuen Version der Microsoft.SharePoint.dll geändert wurde, um stattdessen von der Klasse ASP.NET-Webpart zu erben. Diese Technik, bei der eine Basisklasse in einer späteren Version einer Assembly geändert wird, wird erneute Basiszuordnung genannt. Die erneute Basiszuordnung der Basisklasse WebPart in der Microsoft.SharePoint.dll ist einer der Schlüssel bei der Unterstützung älterer Webparts in einer WSS 3.0-Umgebung.

Abbildung 9: Die Klasse WebPart mit neuer Basiszuordnung
Abbildung 9:   Die Klasse WebPart mit neuer Basiszuordnung

Wenn Sie sich die standardmäßige <B>web.config</B>-Datei für eine WSS 3.0-Webanwendung ansehen stellen Sie fest, dass sie Konfigurationselemente zum Umleiten von Verweisen auf die ältere Version der Microsoft.SharePoint.dll zu der neuen Version enthält. Durch diese Umleitung in Kombination mit der erneuten Basiszuordnung der Basisklasse WebPart können Webpart-DLLs, die für die Umgebung der Version 2 geschrieben wurden, ohne Neukompilierung in der Umgebung der Version 3 ausgeführt werden.

Falls Sie sich entschließen, ein Webpartprojekt der Version 2 für Visual Studio® 2005 zu konvertieren, können Sie Ihren Code in demselben Stil weiterentwickeln wie gehabt, er wird immer noch funktionieren. Ihnen steht jedoch auch noch eine andere Option zur Verfügung, sobald Sie zu Visual Studio 2005 übergegangen sind und den alten Projektverweis auf die Microsoft.SharePoint.dll zu der neuen WSS 3.0-Version verlegt haben. Da die ASP.NET WebPart-Basisklasse jetzt Bestandteil der Vererbungshierarchie ist, können Sie einige Aspekte Ihrer Webpartklasse im WSS-Format ändern, als wäre es ein Webpart im ASP.NET-Format. Dies wird dann als zusammengesetztes Webpart bezeichnet.

Verbesserungen bei der Inhaltsspeicherung

Ein Problem, das Entwickler mit WSS 2.0 hatten, war, dass mehrere wertvolle Features, die in Dokumentbibliotheken unterstützt wurden, nicht auch in Listen unterstützt wurden. Dokumentbibliotheken unterstützten z. B. Versionskontrolle und Ereignisse, Listen aber nicht. In WSS 3.0 unterstützen Listen viele derselben Features wie Dokumentbibliotheken, einschließlich Versionskontrolle, Ereignisse und Ordner. Es gibt auch einige neue Features, die sowohl in Listen als auch in Dokumentbibliotheken unterstützt werden, wie etwa das Offenlegen von Daten durch automatische RSS-Feeds.

Mit WSS 3.0 wird ein neues Spaltenindizierungsfeature eingeführt, um einige Leistungsprobleme zu beheben, die in WSS 2.0 vorhanden waren. Von einer Listeneinstellungsseite oder einer Dokumentbibliothek-Einstellungsseite aus können Sie jeder Spalte einen Index hinzufügen. Dadurch wird nicht unbedingt ein physischer Index in SQL Server erstellt. Stattdessen wird eine Tabelle mit der ganzzahligen ID des Listenelements bzw. Dokuments und dem Wert der indizierten Spalte erstellt. Anhand dieser Tabelle verbessert WSS anschließend die Leistung beim Zurückgeben von Daten aus Ansichten, insbesondere dann, wenn Sie eine Ansicht mit einem Filter verwenden, der auf der indizierten Spalte basiert.

Viele Entwickler vermissten die Möglichkeit, auf einer niedrigeren Ebene mit WSS-Feldern zu arbeiten, um mehr Kontrolle über die Feldwiedergabe und -validierung zu erhalten. Als Reaktion darauf wurden WSS 3.0 neue, erweiterbare Feldtypen hinzugefügt. Sie können einen erweiterbaren Feldtyp erstellen, indem Sie in C# oder Visual Basic® eine Klasse schreiben, die von einem der integrierten SharePoint-Feldtypen wie SPFieldText oder SPFieldNumber erbt. Ein erweiterbarer Feldtyp kann auch ein ASP.NET-Benutzersteuerelement nutzen, das Ihre bevorzugten Websteuerelemente enthält und mit denen Sie dieselben Techniken für die Initialisierung und Validierung der Steuerelemente verwenden können wie in ASP.NET-Anwendungen.

Eine weitere positive Innovation in WSS 3.0 sind benutzerdefinierte Sitespalten. Eine Sitespalte ist eine wieder verwendbare Definition, die auf mehrere Listen angewendet werden kann. Darin werden der Name für eine Spalte, der zugrunde liegende Feldtyp und weitere Merkmale wie der Standardwert, Formatierung und Validierung definiert. Sobald Sie eine Sitespalte definiert haben, können Sie sie beim Definieren der Struktur Ihrer benutzerdefinierten Listen verwenden. Ein offensichtlicher Vorteil ist, dass Sie die Sitespalte an einem Ort aktualisieren können und dass sich diese Aktualisierung auf alle Listen auswirkt, in denen die Sitespalte verwendet wurde. Eine Sitespalte wird im Rahmen einer einzelnen Site definiert, doch sie ist in allen untergeordneten Sites sichtbar. Sie können eine Sitespalte erstellen, die in einer ganzen Websitesammlung verwendet werden kann, indem Sie sie in der Site definieren, die auf der höchsten Ebene steht.

Mit Sitespalten haben Sie die Möglichkeit, siteübergreifende Feldsuchen durchzuführen. Das konnten Sie in früheren Versionen von SharePoint nur erreichen, wenn Sie benutzerdefinierten Code geschrieben haben. Sie können z. B. eine Sitespalte in einer Site auf höchster Ebene erstellen, die eine Suche in einer Liste in derselben Site durchführt. Anschließend können Sie in untergeordneten Sites weitere Listen erstellen, die mit dieser Sitespalte Suchen in der Liste der Site auf der höchsten Ebene durchführen. Stellen Sie sich vor, Sie möchten mehrere verschiedene Dokumenttypen in derselben Dokumentbibliothek speichern. Angenommen, Sie müssen Präsentationen, Angebote und Berichte für Warenhauskunden speichern, und jeder dieser Dokumenttypen soll über seinen eigenen Satz an benutzerdefinierten Spalten und seine eigenen eindeutigen Ereignishandler verfügen. In WSS 2.0 konnten Sie nur weitere Spalten und Ereignishandler zu der Dokumentbibliothek selbst hinzufügen, was sich immer auf jedes Dokument in dieser Dokumentbibliothek auswirkte. Außerdem konnte nur eine Dokumentvorlage mit einer Dokumentbibliothek verknüpft sein.

Mit WSS 3.0 wird ein leistungsfähiger neuer Speichermechanismus namens Inhaltstypen eingeführt, um dieses Problem zu lösen. Ein Inhaltstyp ist ein flexibler und wieder verwendbarer WSS-Typ, der die Form und das Verhalten eines Elements in einer Liste bzw. eines Dokuments in einer Dokumentbibliothek definiert. Sie können z. B. einen Inhaltstyp für ein Kundenpräsentationsdokument mit einem eindeutigen Satz an Spalten, einem Ereignishandler und einer eigenen Dokumentvorlage erstellen. Sie können einen zweiten Inhaltstyp für ein Kundenangebotsdokument mit einem anderen Satz an Spalten, einem Workflow und einer anderen Dokumentvorlage erstellen. Anschließend können Sie eine neue Dokumentbibliothek erstellen und diese so konfigurieren, dass sie beide Inhaltstypen unterstützt. Das ist eine bedeutende Verbesserung, da Sie mit heterogenem Inhalt in Listen und Dokumentbibliotheken arbeiten können.

Ereignishandler

Ereignisse in WSS 2.0 unterstützten Dokumentbibliotheken, aber keine Listen. Darüber hinaus unterstützte Version 2 nur asynchrone Ereignisse, die ausgelöst wurden, nachdem eine Benutzeraktion der SQL Server-Datenbank zugewiesen wurde. Es gab keine Möglichkeit für den Entwickler, die Aktion eines Benutzers in einem Ereignishandler abzubrechen.

WSS 3.0 verbessert die Ereignisverarbeitung, indem Unterstützung für die in Version 2 vorhandenen asynchronen Ereignisse beibehalten und Unterstützung für synchrone Ereignisse hinzugefügt wird, mit denen Sie Benutzeraktionen abbrechen können. Sie können einen Benutzer beispielsweise daran hindern, eine Bestellung mit einem Bestelldatum in der Zukunft zu erstellen oder ein Dokument zu löschen, sobald es genehmigt ist. Ereignisse werden sowohl für Listenelemente als auch für Dokumente in einer Dokumentbibliothek unterstützt.

Sie erstellen einen Ereignishandler, indem Sie eine benutzerdefinierte Klasse schreiben, die von einer der WSS-Empfängerklassen und überschreibenden Methoden zum Verarbeiten von Ereignissen erbt. Wenn Sie z. B. Aktualisierungsereignisse für Elemente in einer Liste verarbeiten möchten, erstellen Sie eine Klasse, die von der Klasse SPItemEventReceiver erbt und die Methode ItemUpdating wie in Abbildung 10 gezeigt überschreibt.

Sie können den Ereignishandler an eine bestimmte Liste oder Dokumentbibliothek binden, indem Sie entweder Code für das Objektmodell schreiben oder in einem WSS-Feature einen Ereignisempfänger definieren. Sie können diesen Ereignisempfänger zum Beispiel mit ähnlichem Code wie dem folgenden an eine Liste binden:

Dim list As SPList = web.Lists("Orders")
list.EventReceivers.Add(SPEventReceiverType.ItemAdding, _
    "[Fully-qualified Assembly name]", "Litware.MyReceiver")

WSS-Empfängerklassen verwenden eine Namenskonvention für überschreibbare Methoden, die zwischen synchronen und asynchronen Ereignissen unterscheidet. ItemUpdating z. B. ist ein abbrechbares, synchrones Ereignis, das ausgelöst wird, bevor die Änderung an der Inhaltsdatenbank vorgenommen wird. Diese synchronen Ereignisse bieten eine hervorragende Möglichkeit, Spaltenwerte zu validieren, wie der Ereignishandler in Abbildung 10 zeigt.

Es gibt ein ergänzendes asynchrones Ereignis namens ItemUpdated, das auftritt, nachdem eine Änderung in die Inhaltsdatenbank geschrieben wurde. Im Gegensatz zu synchronen Ereignissen unterstützen asynchrone Ereignisse das Abbrechen von Benutzeraktionen nicht. Stattdessen bieten sie die Möglichkeit, einen erforderlichen Vorgang durchzuführen, nachdem eine Änderung an einem Dokument oder Listenelement vorgenommen wurde, wie z. B. das Zuweisen eines Wertes einer berechneten Spalte oder das Senden einer E-Mail-Benachrichtigung.

Zusätzlich zum Unterstützen von Ereignissen in Listenelementen und Dokumenten unterstützt WSS 3.0 weitere neue Ereignistypen wie etwa Listenelemente, die ausgelöst werden, wenn eine Listendefinition geändert wird. Sie können z. B. die Aktion eines Benutzers abbrechen, wenn jemand versucht, eine Spalte in einer Ihrer Spaltenlisten umzubenennen bzw. daraus zu entfernen. Es gibt auch Ereignisse, die ausgelöst werden, wenn jemand eine Site oder eine ganze Websitesammlung löscht oder verschiebt.

Workflows in WSS

Workflowanwendungen wird seit kurzem bei Microsoft einige Aufmerksamkeit gezollt. Die WinFX®-Laufzeitkomponenten, die zusammen mit Windows Vista™ herausgegeben werden sollen, fügen eine vollständig neue Infrastruktur – die Windows Workflow Foundation – zum Erstellen von Workflowanwendungen hinzu. Die Workflowinfrastruktur enthält ein Modul, austauschbare Komponenten zum Erhalten des Workflowstatus und einen Visual Studio-Designer, der das Erstellen von benutzerdefinierten Workflows erleichtert, indem als Aktivitäten bezeichnete Komponenten mithilfe von Drag & Drop auf einer Workflowentwurfsoberfläche platziert werden.

WSS 3.0 baut auf Windows Workflow Foundation auf und stellt eine Struktur zum Anhängen von Geschäftslogik an Listenelemente und Dokumente bereit. Das grundlegende Workflowmodell wird erweitert, indem jedem Workflow eine Aufgabenliste und eine Verlaufsliste zugeordnet wird. Dadurch erhalten Workflows ein Maß an Verantwortlichkeit, das sich am Menschen orientiert, wie etwa einen Pfad zum Überprüfen oder Genehmigen eines Dokuments.

Sowohl WSS als auch MOSS 2007 werden mit installierten Workflows bereitgestellt, die sofort verwendet werden können. WSS 3.0 beinhaltet einige einfache Routingworkflows für Aktionen wie Moderation und Genehmigung. MOSS 2007 bietet komplexere Workflows, die Features wie den Genehmigungsprozess von Webinhaltsmanagement unterstützen.

Das Erstellen benutzerdefinierter Workflows stellt offensichtlich einen Punkt zur Erweiterbarkeit für Entwickler dar, die mit WSS und MOSS 2007 Geschäftslösungen erstellen. Zusätzlich zur Standardunterstützung der Visual Studio-Erweiterungen für Windows Workflow Foundation existieren Pläne, ein WSS-spezifisches Workflow-SDK und ein Starter Kit bereitzustellen, das Visual Studio-Projektvorlagen zum Erstellen benutzerdefinierter Workflows für WSS-Sites enthält.

SharePoint Designer bietet auch Unterstützung zum Erstellen benutzerdefinierter Workflows in WSS 3.0-Sites. Damit werden die Hauptbenutzer ebenso sehr wie oder noch stärker angesprochen als die Entwickler, weil sie dadurch eine Möglichkeit erhalten, einen Assistenten zu durchlaufen und in einer Produktionssite Geschäftslogik an Listenelemente und Dokumente anzuhängen.

Sitedefinitionen, Features und Lösungen

Entwickler, die mit WSS 2.0 als Plattform Geschäftslösungen erstellt haben, stellten fest, dass die Arbeit mit Sitedefinitionen auf niedriger Ebene das größte Maß an Kontrolle und Wiederverwendbarkeit bietet. Eine Sitedefinition ist ein Verzeichnis im Front-End-Webserver, das XML-Dateien und ASPX-Seitenvorlagen enthält, die eine Blaupause für die Site festlegen, einschließlich Listenschemata und Seitenlayouts. Die auf XML basierende Sprache, die in vielen Sitedefinitionsdateien verwendet wird, heißt Collaborative Application Markup Language (CAML).

In Version 2 gab es jedoch einige Probleme mit dieser Strategie. Zunächst waren die XML-Dateien in Version 2 schlecht ausgearbeitet; dadurch wurden sie unhandlich, und es war schwierig, damit zu arbeiten. Zweitens gab es keine Unterstützung für die Weiterentwicklung einer Sitedefinition, sobald sie zum Erstellen von Sites verwendet worden war. Das bedeutet, es gab keine unterstützte Technik für Sitedefinitionen, mit der Funktionalität zu einer vorhandenen WSS 2.0-Site hinzugefügt werden konnte. Drittens schufen Sitedefinitionen und die benutzerdefinierten Assemblys, von denen sie abhängen, Bereitstellungsprobleme, da die Dateien ohne jegliche Unterstützung der WSS-Infrastruktur auf jeden Front-End-Webserver in einer Farm geschoben werden mussten. Und schließlich bot WSS 2.0 keine Möglichkeit, eine Sitedefinition zu lokalisieren – eine ziemlich frustrierende Situation für Unternehmen, die ihre Geschäftslösungen internationalisieren wollten.

Die erste bedeutende WSS 3.0-Verbesserung in diesem Bereich ist die Einführung von Features. Ein Feature ist wie eine Sitedefinition: ein Verzeichnis, das auf CAML basierende XML-Dateien und Seitenvorlagen enthält. Doch Features bieten einen weitaus modulareren Ansatz, da Sie nicht die gesamte Blaupause für eine Site definieren müssen. Stattdessen kann ein einfaches Feature ein einzelnes Siteelement, wie z. B. eine benutzerdefinierte Listendefinition oder Menübefehle, definieren, die dann in einem der Standardmenüs von WSS angezeigt werden.

Glücklicherweise können Features in einer vorhandenen Site aktiviert werden. Sie können beispielsweise ein Feature erstellen, das einen benutzerdefinierten Listentyp erstellt, eine Instanz dieses Listentyps und einen Ereignishandler oder Workflow für diese Listeninstanz. Sobald das Feature installiert ist, kann es in jeder Site innerhalb einer Farm aktiviert werden. Dies ist über die Benutzeroberfläche von WSS möglich, von der Befehlszeile aus, oder mithilfe von benutzerdefiniertem Code, der für das WSS-Objektmodell geschrieben wurde. Sobald das Feature aktiviert ist, enthält die Site Ihre neue benutzerdefinierte Liste und jegliches Verhalten, das sie ihr zuweisen möchten.

Features vereinfachen außerdem das Entwickeln von Sitedefinitionen. In WSS 2.0 musste jede Listendefinition innerhalb des Kontexts einer Sitedefinition angegeben werden. In Version 3 kann jede Listendefinition in ihr eigenes Feature ausgearbeitet werden. Sitedefinitionen sind jetzt leichter zu erstellen, da sie mit Featureverweisen zusammengesetzt werden können. Dieser Ansatz wird bei allen Listentypen verwendet, die als Bestandteil der WSS Services für Collaboration bereitgestellt werden.

WSS 3.0 stellt einen neuen Bereitstellungsmechanismus vor, der Lösung genannt wird. Er ähnelt den Webpart-Paketen insofern, als es sich um eine zusammengefasste CAB-Datei mit XML-Anweisungen und -Dateien handelt, die auf jedem Front-End-Webserver bereitgestellt werden müssen. Lösungen gehen jedoch über Webpart-Pakete hinaus und unterstützen die Bereitstellung von Features, Sitedefinitionen und verwandten Assemblys für Ereignishandler und Workflows.

Die Unterstützung von WSS 3.0 für Lösungen hilft auch, Bereitstellungsdateien auf jeden Webserver in einer Farm zu schieben. Ein Administrator fügt eine Lösung zu einer WSS-Farm hinzu, die die CAB-Datei der Lösung in die Konfigurationsdatenbank kopiert. Als Nächstes führt der Administrator einen Befehl aus, um die Lösung bereitzustellen. Zum gleichen Zeitpunkt startet WSS einen Timerauftrag, um die CAB-Datei der Lösung auf jeden Webserver zu schieben und zu installieren.

Eine sehr willkommene Änderung für WSS-Entwickler ist die neue Unterstützung für Lokalisierung. Diese Funktionalität baut auf der Lokalisierungsinfrastruktur von ASP.NET 2.0 auf, und jetzt ist es möglich (und empfehlenswert), Sitedefinitionen und Features sprachneutral zu erstellen und Zeichenfolgenliterale in RESX-Dateien zu verwalten. Innerhalb der XML-Dateien und ASPX-Seitenvorlagendateien für ein Feature oder eine Sitedefinition können Sie den Wert für eine benannte Zeichenfolge erwerben, die mit der standardmäßigen ASP.NET-Syntax in eine RESX-Datei lokalisiert wurde.

<%$Resources:Litware,MyString%>

Internetsicherheitsfeatures

In WSS 2.0 basierte die Authentifizierung auf Windows-Konten und den damit verknüpften Sicherheits-IDs (SIDs). In der Praxis bedeutete dies, dass WSS 2.0 eng mit Active Directory® gekoppelt war; nur kleinste Bereitstellungen blieben davon unbeeinflusst. Diese Abhängigkeit war kein Problem für Unternehmen, die Active Directory bereitstellten, als sie begannen, mit WSS 2.0 und SharePoint Portal Server 2003 intranetbasierte Lösungen zu erstellen. Doch für Unternehmen, die extranetbasierte Lösungen erstellten, war die Herausforderung größer. Die enge Kopplung von WSS an Active Directory zwang Unternehmen, Domänenkonten für Benutzer außerhalb der Firma, wie z. B. Hersteller und Kunden, zu erstellen und zu verwalten.

All das ändert sich mit WSS 3.0, da die Authentifizierung auf der neuen, mit ASP.NET 2.0 eingeführten Infrastruktur für Authentifizierungsanbieter neu entworfen wurde. Wenn Sie in Active Directory keine Benutzerkonten für WSS- und MOSS 2007-Sites verwalten möchten, erstellen oder erwerben Sie einfach einen ASP.NET-Authentifizierungsanbieter, der zum Speichern und Verwalten von Benutzerkonten in einem anderen Identitäten-Repository entwickelt wurde.

ASP.NET 2.0 wird beispielsweise mit dem Formularauthentifizierungsanbieter geliefert, mit dem Sie Benutzerkonten in einer SQL Server-Datenbank verwalten können. Dieser Authentifizierungsanbieter kann für die Verwendung in einer WSS-Site konfiguriert werden. Mit ein wenig Mühe können Sie eine WSS-Site im Internet bereitstellen, die es unbekannten Benutzern ermöglicht, sich selbst als Mitglieder zu registrieren. ASP.NET 2.0 bietet komfortable Unterstützung zum Erstellen und Verwalten von Benutzerkonten und ermöglicht Benutzern sogar, ihre Kennwörter zu ändern und zurückzusetzen.

Schlussbemerkung

Es wurden viele der Hauptfortschritte in WSS 3.0 behandelt, die auf Entwickler abzielen, und Sie werden noch viele weitere entdecken, sobald Sie sich mit dem Produkt beschäftigen und damit arbeiten. Es sollte bereits deutlich geworden sein, dass das WSS-Team sich das Entwicklerfeedback zu der Vorgängerversion zu Herzen genommen und mit einigen bedeutsamen neuen Features reagiert hat.

Der Autor

Ted Pattison ist Autor und Trainer, der durch sein Unternehmen, die Ted Pattison Group, praktische Schulungen anbietet. Ted betreibt derzeit Nachforschungen für ein neues Buch mit den Schwerpunkten Windows SharePoint Services 3.0 und Servertechnologie von Office 12.

Ausgabe von Juli 2006 des MSDN-Magazins.


Anzeigen:
© 2015 Microsoft