Fabian´s Blog [SharePoint MVP] : Webpart-Entwicklung

Eigene Webparts in der Liste der vorgeschlagenen Webparts unterbringen

Fabian Moritz — Mon, 05 Oct 2009 05:38:45 GMT

In der Standardeinstellung listet der Webpart Picker die innerhalb einer Site Collection angebotenen Webparts in den Kategorien „Listen und Bibliotheken“ sowie „Alle Webparts“ auf.

Einige Seitenvorlagen (z.B. die Suchergebnisseite) liefern darüber hinaus noch die zusätzliche Kategorie „Vorgeschlagene Webparts für …“, in der speziell die für die jeweilige Zone empfohlenen Webparts aufgelistet werden. Eine, wie ich finde, sehr nützliche Funktion. Wie kann nun dieses Feature für eigene Webparts genutzt werden. Zwei Dinge sind hierfür erforderlich: Zunächst muss in der Webpart-Galerie (Websiteeinstellungen > Webparts) für die betreffenden Webparts eine QuickAdd-Gruppe (Gruppen schnell hinzufügen) definiert werden.

Außerdem muss in dem entsprechenden Seitenlayout oder in der SharePoint Seite die Webpart-Zone um das Attribut QuickAdd-GroupNames erweitert werden.

   1: <WebPartPages:WebPartZone runat="server" QuickAdd-GroupNames="My Webparts" ID="Left" Title="Left">

   2:     <ZoneTemplate>

   3:     </ZoneTemplate>

   4: </WebPartPages:WebPartZone>

Das war es auch schon! Nach diesen beiden simplen Anpassungen werden auch benutzerdefinierte Webparts in der Liste der empfohlenen Webparts dargestellt.

Wer möchte, kann für einen Webpart oder eine Webpart-Zone auch mehrere QuickAdd-Gruppen definieren.

SharePoint Security - Teil 2: Impersonifizierung von Benutzeridentitäten

Fabian Moritz — Fri, 13 Mar 2009 09:39:24 GMT

ITaCS Change Password Web Part 2.0 (Beta) veröffentlicht

Fabian Moritz — Thu, 05 Feb 2009 11:50:12 GMT

Erfreut kann ich berichten, dass die neue Version unseres bekanntesten Produkts, ITaCS Change Password Web Part 2.0, verfügbar ist.

Der kostenlose Webpart vereint die beiden Vorgängerversionen Change my Active Directory Password und Change my local Password und liefert weitere zahlreiche Neuerungen. Zu den wichtigsten Änderungen gehören:

Auswahl zwischen Active Directory oder lokaler Benutzerdatenbank
Unterstützung von AJAX und eine verbesserte Benutzerfreundlichkeit
Mehrsprachigkeit: Englisch, Deutsch, Französisch oder benutzerdefiniert (Einstellung der Label-Texte innerhalb des Webparts)
Skin Support (Integrierte Skin-Sammlung, die um benutzerdefinierte Skins erweitert werden kann)
BIN-Deployment (der Webpart wird nicht mehr in den Global Assembly Cache deployt)
Darstellung der internen Fehlermeldungen vom Active Directory (z.B. Kennwortrichtlinien)
Verbesserte Installation und Performance

Der Webpart wird über ein Installationspaket in der SharePoint-Umgebung bereitgestellt. Die SharePoint Solution (inkl. Dokumentation) kann auf dieser Webseite heruntergeladen werden. Zudem könnt ihr den Webpart ab heute auch auf Codeplex finden: http://www.codeplex.com/ChangePassword Bitte beachtet, dass es sich bei dieser Version um eine Beta-Version handelt. Wir freuen uns auf euer Feedback!

ITaCS Change Password Web Part 2.0 – Beta

Our newest product, ITaCS Change Password Web Part 2.0, is now available. This free Web Part replaces the previous versions, Change my Active Directory Password Web Part and Change my local Password Web Part. The Change Password 2.0 merges the functionality of both previous releases and comes with enhanced features designed for easier integration and customization.

ITaCS Change Password Web Part 2.0 is packed with a variety of new features enabling administrators to:

Choose between Active Directory and local Computer environment
Select one of the built in languages (English, German, French) or define custom output labels
Switch among various error modes and subsequent messages displayed to the users
Decide on one of several included design templates or construct their own styles
AJAX support

Interested customers, users and partners can take advantage of the ITaCS Change Password Web Part 2.0 Beta version. We look forward to your feedback.

The SharePoint Solution can be downloading from this website. Please consider this version of the web part a BETA Version.

Silverlight Clock Webpart

Fabian Moritz — Mon, 17 Nov 2008 07:09:30 GMT

Als Ergänzung zu den einführenden Artikeln (Links stehen unten) soll dieses Beispiel demonstrieren, wie eine vollständige Silverlight-Anwendung in einer SharePoint-Umgebung bereitgestellt werden kann. Dieser Webpart hostet ein Silverlight Control, das durch die SharePoint Solution automatisch in das ClientBin-Verzeichnis der Ziel-Webanwendung deployt wird. Das Deployment wird durch ein Feature Receiver realisiert:

   1: public override void FeatureInstalled(SPFeatureReceiverProperties properties)

   2: {

   3:      SPFarm farm = properties.Definition.Farm;

   4:      SPSolution sol = farm.Solutions["FM.Demos.SilverlightAnalogClockWebPart.wsp"];

5:

   6:      foreach (SPWebApplication app in sol.DeployedWebApplications)

   7:      {

   8:            SPIisSettings iisSettings = app.IisSettings[SPUrlZone.Default];

9:

  10:            string sourcePath = String.Format(@"{0}\FEATURES\{1}",

  11:            SPUtility.GetGenericSetupPath("Template"), @"SilverlightAnalogClockInstaller\SilverlightAnalogClock.xap");

  12:            string destPath = String.Format(@"{0}\ClientBin\SilverlightAnalogClock.xap", iisSettings.Path.ToString());

  13:            File.Copy(sourcePath, destPath);

  14:      }

  15: }

Der Feature Receiver sorgt während der Installation des Features (FeatureInstalled) für ein automatisches Deployment der XAP-Datei. Über das (hier nicht aufgelistet) FeatureUninstalling-Event wird die XAP-Datei ggf. wieder vom SharePoint Frontend Server entfernt.

Zusätzlich zu dieser Funktion implementiert der Webpart ein benutzerdefiniertes Template, das gerendert wird, wenn auf dem Client-Computer die aktuelle Silverlight-Version nicht installiert ist.

   1: protected override void CreateChildControls()

   2: {

   3:     base.CreateChildControls();

   4:     silverlightControl = new Silverlight();

   5:     silverlightControl.ID = "SilverlightAnalogClock";

   6:     silverlightControl.Source = "/ClientBin/SilverlightAnalogClock.xap";

   7:     silverlightControl.Width = Unit.Pixel(260);

   8:     silverlightControl.Height = Unit.Pixel(260);

   9:     silverlightControl.PluginNotInstalledTemplate = new SilverlightPluginNotInstalledTemplate();

10:

  11:     this.Controls.Add(silverlightControl);

  12: }

13:

  14: public class SilverlightPluginNotInstalledTemplate : ITemplate

  15: {

  16:     const string fwLink = "http://go.microsoft.com/fwlink/?LinkID=124807";

  17:     const string imgLink = "/_layouts/images/FM/SilverlightClockInstallSilverlight.png";

18:

  19:     public SilverlightPluginNotInstalledTemplate()

  20:     {

  21:     }

22:

  23:     public void InstantiateIn(Control container)

  24:     {

  25:          string pluginTemplateLink = String.Format(@"<a href='{0}' style='text-decoration: none;'>"+

  26:                  "<img src='{1}' alt='Get Microsoft Silverlight' style='border-style: none'/></a>",

  27:                  fwLink, imgLink);

28:

  29:          LiteralControl ltr = new LiteralControl(pluginTemplateLink);

  30:          container.Controls.Add(ltr);

  31:     }

  32: }

Die vollständige SharePoint Solution sowie die Visual Studio Projektdatei können über folgende Links heruntergeladen werden:

Feedback und Hinweise sind gerne Willkommen!

Silverlight Controls in Webparts hosten

Fabian Moritz — Tue, 28 Oct 2008 07:58:21 GMT

Nachdem ich in zwei vorangestellten Artikeln beschrieben hatte, wie eine SharePoint-Umgebung für die Integration von ASP.NET 3.5 AJAX und Silverlight vorbereitet wird, möchte ich heute zeigen, wie Silverlight Controls über einen Webpart gehostet werden können.

.NET Framework 3.5 AJAX und Silverlight in SharePoint registrieren

Silverlight (Beta 2 oder RC0) in SharePoint-Anwendungen aktivieren

1. Webpart Class Library erstellen
Zunächst muss das Grundgerüst des Webparts auf Basis einer .NET Framework 3.5 Klassenbibliothek erstellt werden. Dazu muss der Namensraum System.Web registriert werden und die Webpart-Klasse von System.Web.UI.WebControls erben.

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Linq;

   4: using System.Text;

   5: using System.Web.UI.WebControls.WebParts;

   6: using System.Web.UI;

   7: using System.Web.UI.WebControls;

8:

   9: namespace FM.Demos

  10: {

  11:     public class HelloSilverlightWebPart : WebPart

  12:     {

  13:         public HelloSilverlightWebPart()

  14:         {

  15:         }

16:

  17:         protected override void CreateChildControls()

  18:         {

  19:             base.CreateChildControls();

  20:         }

  21:      }

  22: }

2. System.Web.Silverlight Assembly registrieren
Die durch das Silverlight SDK mitglieferte Assembly kann direkt aus dem SDK referenziert werden. C:\Program Files\Microsoft SDKs\Silverlight\v2.0\Libraries\Server\System.Web.Silverlight.dll

Hinweis: Die Assembly muss für den Betrieb in SharePoint-Umgebungen im Global Assembly Cache bereitgestellt werden.

3. Silverlight Control implementieren
Nachdem die vorbereitenden Schritte erledigt sind, kann innerhalb der Webpart-Klasse das Silverlight-Control erstellt und konfiguriert werden.

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Linq;

   4: using System.Text;

   5: using System.Web.UI.WebControls.WebParts;

   6: using System.Web.UI;

   7: using System.Web.UI.SilverlightControls;

   8: using System.Web.UI.WebControls;

9:

  10: namespace FM.Demos

  11: {

  12:     public class HelloSilverlightWebPart : WebPart

  13:     {

  14:         Silverlight silverlightControl = null;

15:

  16:         public HelloSilverlightWebPart()

  17:         {

  18:         }

19:

  20:         protected override void OnInit(EventArgs e)

  21:         {

  22:             EnsureScriptManager();

  23:         }

24:

  25:         protected override void CreateChildControls()

  26:         {

  27:             base.CreateChildControls();

  28:             silverlightControl = new Silverlight();

  29:             silverlightControl.ID = "silverlightControl";

  30:             silverlightControl.Source = "/ClientBin/HelloSilverlight.xap";

  31:             silverlightControl.Width = Unit.Pixel(400);

  32:             silverlightControl.Height = Unit.Pixel(200);

33:

34:

  35:             this.Controls.Add(silverlightControl);

  36:         }

37:

  38:         private void EnsureScriptManager()

  39:         {

  40:             ScriptManager scriptManager = ScriptManager.GetCurrent(this.Page);

41:

  42:             if (scriptManager == null)

  43:             {

  44:                 scriptManager = new ScriptManager();

  45:                 scriptManager.EnablePartialRendering = true;

46:

  47:                 if (Page.Form != null)

  48:                 {

  49:                     Page.Form.Controls.AddAt(0, scriptManager);

  50:                 }

  51:             }

  52:         }

  53:     }

  54: }

Die vermutlich wichtigste Eigenschaft ist die Source. Sie definiert den Server-seitigen Pfad zum Silverlight Control (XAP-Datei). In meinem Beispiel habe ich dem Steuerelement noch eine ID, sowie die Höhe und Breite mitgegeben.

In der OnInit-Methode wird über eine Hilfsmethode geprüft, ob der AJAX ScriptManager auf der Webseite vorhanden ist und ggf. der Page hinzugefügt.

4. Silverlight Control bereitstellen
Das Silverlight Control (XAP-Datei) muss unterhalb der Webanwendungsdateien (z.B. C:\inetpub\wwwroot\wss\VirtualDirectories\Intranet) in einem dedizierten Verzeichnis bereitstellt werden (in meinem Beispiel ClientBin), wonach es durch den Webpart innerhalb einer SharePoint-Seite ausgeliefert werden kann.

Das vollständige Beispiel incl. Feature, SharePoint Solution sowie des Beispiel Controls kann hier heruntergeladen werden.

Webpart programmatisch einer SharePoint-Seite hinzufügen

Fabian Moritz — Sun, 28 Sep 2008 09:37:16 GMT

Hier ein Beispiel, wie ein Listenansichts-Webpart (ListViewWebPart) über Programmcode einer SharePoint Site hinzugefügt werden kann. Die SPLimitedWebPartManager-Klasse ist neu in WSS 3.0 und liefert weit reichende Möglichkeiten, Webparts einer SharePoint-Seite zu verwalten. Das folgende Beispiel demonstriert, wie ein Webpart über die AddWebPart-Methode einer definierten Webpart-Zone hinzugefügt wird.

   1: using (SPSite site = new SPSite("http://intranet/demos/features"))

   2: {

   3:     using (SPWeb web = site.OpenWeb())

   4:     {

   5:         // Connect to a list an create a ListViewWebPart object

   6:         SPList listDocs = web.Lists[new Guid("{EA98DB28-51B3-41D7-8A96-B1C55328020B}")];

   7:         ListViewWebPart webpart = new ListViewWebPart();

   8:         webpart.ListName = listDocs.ID.ToString("B").ToUpper();

   9:         webpart.ViewGuid = listDocs.DefaultView.ID.ToString("B").ToUpper();

10:

  11:         // Open the WSS Default Site and add the ListViewWebPart to the top of the left onez

  12:         SPFile file = web.Files["default.aspx"];

  13:         SPLimitedWebPartManager manager = file.GetLimitedWebPartManager(PersonalizationScope.Shared);

  14:         manager.AddWebPart(webpart, "Left", 0);

  15:     }

  16: }

AJAX in SharePoint Webparts – Teil 2: Conditional Update und Trigger

Fabian Moritz — Sun, 29 Jun 2008 11:36:17 GMT

In meinem einleitenden Beispiel hatte ich bereits angedeutet, dass der UpdateMode eines UpdatePanels standardmäßig auf „Auto“ gesetzt ist, was zur Folge hat, das die Inhalte eines UpdatePanels bei jedem Rückruf aktualisiert wird. Prinzipiell stellt dieser Umstand auch kein Problem dar, jedoch werden spätestens bei der Verwendung von mehreren UpdatePanels innerhalb einer SharePoint Webseite die Seiteneffekte sichtbar. Durch den automatischen UpdateMode werden, je nach Reihenfolge der Events, alle UpdatePanels einer Seite aktualisiert, was in einigen Anwendungen vermutlich nicht unbedingt gewünscht ist.

Für diesen Fall stellen die ASP.NET Extensions die Option bereit, den UpdateMode des UpdatePanels auf „Conditional“ zu ändern und über einen Trigger zu definieren, bei welchem Event der Inhalt eines Panels aktualisiert wird.

Folgende zwei einfache Schritte sind für die Implementierung eines Triggers innerhalb eines SharePoint Webparts erforderlich.

Hinweis: In meinem Beispiel werde ich den Webpart aus dem ersten Teil der Artikelserie erweitern.

1. AsyncPostBackTrigger erzeugen
Das UpdatePanel unterstützt zwei Typen von Triggern. Der AsyncPostBackTrigger implementiert einen asynchronen Aufruf, wobei der PostBackTrigger eine synchrone Verarbeitung erzwingt. Der AsyncPostBackTrigger wird innerhalb der OnInit-Methode instanziiert.

AsyncPostBackTrigger trigger;

       protected override void OnInit(EventArgs e)

...

           btnSend = new Button();

           btnSend.ID = "btnSend";

           btnSend.Text = "Click me...";

           btnSend.Click += new EventHandler(btnSend_Click);

...

           // Init Trigger and attach to UpdatePanel

           trigger = new AsyncPostBackTrigger();

           trigger.ControlID = btnSend.UniqueID;

           trigger.EventName = "Click";

...

Über die Eigenschaft ControlID wird dem Trigger die eindeutige ID des zu überwachenden Controls zugewiesen und im Anschluss das Ereignis definiert, bei dem der Trigger feuern soll. Das Control sollte eine Code-seitig vergebene ID besitzen, andernfalls kann es beim Aufruf des Webparts zu folgender Exception kommen:

System.InvalidOperationException: The ControlID property must be set on the trigger in UpdatePanel 'updatePanel'.

2. UpdateMode ändern und Trigger registrieren
Im Anschluss kann der UpdateMode des UpdatePanels auf UpdatePanelUpdateMode.Conditional geändert und der Trigger dem UpdatePanel hinzugefügt werden.

protected override void OnInit(EventArgs e)

...

            // Init UpdatePanel

            updatePanel = new UpdatePanel();

            updatePanel.ID = "updatePanel";

            updatePanel.UpdateMode = UpdatePanelUpdateMode.Conditional;

            // Init Trigger and attach to UpdatePanel

            trigger = new AsyncPostBackTrigger();

            trigger.ControlID = btnSend.UniqueID;

            trigger.EventName = "Click";

            updatePanel.Triggers.Add(trigger);

...

Sollte es erforderliche sein, auf mehrere Events zu reagieren, können dem UpdatePanel noch weitere Trigger hinzugefügt werden.

Nach Implementierung des Triggers werden die Click-Events der beiden Webparts getrennt voneinander ausgeführt und das jeweilige UpdatePanel separat aktualisiert.

Als ergänzende Variante kann die Aktualisierung des UpdatePanels auch direkt über die Update-Methode des Controls erzwungen werden.

Das erweiterte Beispiel steht wie gewohnt als Visual Studio Projekt zum Download bereit.

AJAX-Funktionen in SharePoint Webparts integrieren

Fabian Moritz — Sat, 28 Jun 2008 10:57:00 GMT

Mit den ASP.NET Extension 1.0, dem .NET Framework 3.5 und dem Service Pack 1 stellen die Windows SharePoint Services und der Office SharePoint Server die offizielle Möglichkeit bereit, AJAX Controls und Features in SharePoint-Webparts zu verwenden. In diesem Artikel werde ich Schritt für Schritt beschreiben, wie diese Funktionen in einen Webpart integriert werden und was die Voraussetzungen sind.

Zunächst möchte ich mich mit der Frage auseinandersetzen, was eigentlich AJAX bedeutet und was mir diese Technologie bringt. AJAX ist die Abkürzung für Asynchronous JavaScript and XML. Die Grundidee von AJAX ist der partielle Seitenaufruf, was bedeutet, dass nur spezielle Seitenfragmente einer Webseite an den Server gesendet werden. In diesem Verfahren wird auf ein vollständiges Postback der Seite verzichtet und das Fragment der Seite asynchron abgearbeitet, was zur Folge hat, dass während des Aufrufs der Benutzer weiterhin mit der Seite interagieren kann. Die Daten werden über XMLHttpRequest-Objekt über JavaScript verarbeitet. Wer mit Client-seitigem Scripting keine Erfahrung hat, muss an dieser Stelle keine Angst haben. Für die Umsetzung von asynchronen Seitenaufrufen stellt Microsoft ein Framework bereit: ASP.NET Extensions 1.0. Die Erweiterungen liefern eine Reihe von Controls und Komponenten für die Umsetzung von AJAX-Anwendungen. Zu den wichtigsten Controls zählen:

ScriptManager. Das ScriptManager-Control sorgt für die Auslieferung aller erforderlichen Script-Bibliotheken am Client. Der ScriptManager ist für die Umsetzung von ASP.NET AJAX-Anwendungen zwingen erforderlich. Pro Webseite darf jeweils nur ein ScriptManager enthalten sein.

ScriptManagerProxy. Dieses Steuerelement wird in ASP.NET für Master und Content Pages verwendet. Der ScriptManagerProxy ermöglicht eingebetteten Content Pages oder User Controls Script-Referenzen an eine Masterseite zu senden, die bereits einen ScriptManager enthält.

UpdatePanel. Das wohl wichtigste Control realisiert das partielle Page Rendering und tauscht automatisch Seitenfragment mit dem Server aus. Pro Seite kann es einen oder mehrere UpdatePanels geben, die getrennt voneinander ausgeführt werden können. Die Aktualisierung kann automatisch oder konditionell ausgeführt werden. Das „Conditional“ Update wir auf Basis eines Triggers ausgeführt. Der Trigger steuert das Control und das Event, bei dem die Inhalte eines UpdatePanels aktualisiert werden sollen.

UpdateProgress. Das UpdateProgress-Steuerelement gibt dem Entwickler die Möglichkeit, auf den Aktualisierungsvorgang des UpdatePanels sowohl visuell als auch funktional Einfluss zu nehmen. Klassischer Weise wird über das UpdateProgress eine Grafik oder HTML-Elemente gerendert, die auf den Aktualisierungsprozess hinweisen. Zusätzlich kann das Control ein Button integrieren, mit dem der Prozess abgebrochen werden kann. Client-seitig muss dazu die Funktion abortPostBack() aufgerufen werden.

Timer. Das letzte Control der ASP.NET Extensions liefert die Möglichkeit, den Aktualisierungsprozess des UpdatePanels zeitgesteuert in definierten Intervallen auszuführen.

Nach Installation der ASP.NET Extensions 1.0 werden die darin enthaltenen Controls in der Visual Studio Toolbox registriert und können über Drag & Drop auf eine ASP.NET Webseite oder ein User Control positioniert werden.

In der Webpart-Entwicklung müssen die Controls Code-seitig erzeugt werden. Folgende Voraussetzungen sind für die Verwendung von ASP.NET AJAX für SharePoint Webparts erforderlich.

1. Installation der ASP.NET Extensions 1.0
Die Extensions in der Version 1.0 sind für ASP.NET 2.0-Webparts erforderlich. Das kostenlose Installationspaket kann von http://www.asp.net/ajax/downloads heruntergeladen werden.

2. (oder) Installation des .NET Frameworks 3.5
Das .NET Framework 3.5 integriert prinzipiell die Controls der ASP.NET Extensions 1.0 und erweitert sie um zwei zusätzliche Funktionen, wie zum Beispiel Dynamic Data, AJAX Browser History, Script Combining, ADO.NET Data Services und das ADO.NET Entity Framework. Weitere Informationen zu den Erweiterungen liefert diese Webseite. http://www.asp.net/downloads/3.5-SP1/default.aspx#features

3. Registrierung der AJAX-Komponenten in der web.config.
Wer das SharePoint Service Pack 1 nicht installiert hat, muss die AJAX-Erweiterungen manuell in der web.config-Datei der Webanwendung registrieren. Eine ausführliche Anleitung der einzelnen Schritte liefert Mike Ammerlaand´s Weblog. Alternativ können die Einstellungen auch automatisch über das AJAX.Config Feature von Codeplex registriert werden.

Danach kann ein bestehender oder neuer Webpart um AJAX-Funktion erweitert werden. In meinem Beispiel begnüge ich mich mit einem einfachen Webpart, der zwei Labels und einen Button enthält. Beide Labels werden mit der aktuellen Zeit initialisiert. Nach einem Klick auf den Button wird der Wert des unteren Labels überschrieben. Da die gesamte Seite durch einen Postback an den Server gesendet und vollständig verarbeitet wird, ist das Ergebnis der Ausführung des Buttons, dass die Zeit beider Labels aktualisiert wird. Vor der Ausführung des Click-Events werden alle Controls des Webparts abgearbeitet gerendert, was zur Folge hat, dass beide Labels die neue Zeit darstellen. Diesen Umstand möchte ich durch die Verwendung des UpdatePanels ändern.

Das untere Label und den Button werde ich in ein UpdatePanel packen, so dass nach dem "Click" auf den Button nur noch die Daten des zweiten Labels aktualisiert werden. Folgende Schritte sind für diese Umsetzung erforderlich:

1. Referenz auf System.Web.Extension
Die ASP.NET Extensions müssen im Webpart-Projekt als Referenz hinzugefügt werde. Die AJAX-Controls werden über den Namensraum System.Web.UI bereitgestellt.

2. ScriptManager registrierten
Die für AJAX zwingend erforderlichen JavaScript-Libraries werden durch den ScriptManager ausgeliefert. Es gibt verschiedenen Möglichkeiten den ScriptManger in eine Webseite einzubetten. In die Master Page, in ein Page Layout oder im Webpart selbst. Pro Seite kann jeweils nur eine ScriptManager eingebettet werden. Da man nicht davon ausgehen kann, dass in der Zielanwendung der ScriptManager dauerhaft vorhanden ist, empfehle ich innerhalb des Webparts zu prüfen, ob die Seite einen ScriptManger enthält und ggf. eine neue Instant zu registrieren. Folgendes Codebeispiel veranschaulicht diesen Prozess.

private void EnsureScriptManager()

            ScriptManager scriptManager = ScriptManager.GetCurrent(this.Page);

            if (scriptManager == null)

                scriptManager = new ScriptManager();

                scriptManager.EnablePartialRendering = true;

                if (Page.Form != null)

                    Page.Form.Controls.AddAt(0, scriptManager);

Die Methode sollte in OnInit aufgerufen werden.

protected override void OnInit(EventArgs e)

           base.OnInit(e);

           EnsureScriptManager();

3. UpdatePanel BUG für SharePoint beseitigen.
Die Windows SharePoint Services überschreiben die default form action über ein spezielles JavaScript, um mit Double Byte encodeten URLs in Postbacks umzugehen. Sollte im Webpart ein _doPostBack verwendet werden, zum Beispiel durch einen LinkButton, kann diese Funktion in Verbindung mit einem asynchronen Aufrufen zu Problemen führen. Um dieses Problem zu beheben, muss der SharePoint Workaround mit einem benutzerdefinierten Client Script überschrieben werden, der zu folgendem Ergebnis führt.

<script type='text/javascript'>   1: _spOriginalFormAction = document.forms[0].action; _spSuppressFormOnSubmitWrapper=true;
</script>

Dieses Script kann durch folgende Methode innerhalb des Webparts registriert werden.

private void EnsureUpdatePanelFixups()

            if (this.Page.Form != null)

                string formOnSubmitAtt = this.Page.Form.Attributes["onsubmit"];

                if (formOnSubmitAtt == "return _spFormOnSubmitWrapper();")

                    this.Page.Form.Attributes["onsubmit"] = "_spFormOnSubmitWrapper();";

            ScriptManager.RegisterStartupScript(this, this.GetType(),

                "UpdatePanelFixup", "_spOriginalFormAction = document.forms[0].action; _spSuppressFormOnSubmitWrapper=true;", true);

Die Mothode kann nach der Registrierung des ScriptManager in OnInit aufgerufen werden.

protected override void OnInit(EventArgs e)

           base.OnInit(e);

           EnsureScriptManager();

           EnsureUpdatePanelFixups();

Weitere Informationen zu dem Workaround liefert folgender KB-Artikel. http://support.microsoft.com/kb/941955/en-us

4. UpdatePanel integrieren

Im letzten Schritt kann das UpdatePanel in den Webpart integriert werden. Die Inititalisierung findet in OnInit statt. Dem Control muss eine eindeutige ID vergeben werden. Diese Einstellung ist besonders für der Verwendung von Conditional Update wichtig (dazu später). Im Anschluss können die Controls dem Panel hinzugefügt werden.

protected override void OnInit(EventArgs e)

            base.OnInit(e);

            EnsureScriptManager();

            EnsureUpdatePanelFixups();

            // Init Controls

            lblDateTime1 = new Label();

            lblDateTime1.Text = DateTime.Now.ToString();

            lblDateTime2 = new Label();

            lblDateTime2.Text = DateTime.Now.ToString();

            btnSend = new Button();

            btnSend.Text = "Click me...";

            btnSend.Click += new EventHandler(btnSend_Click);

            // Init UpdatePanel

            updatePanel = new UpdatePanel();

            updatePanel.ID = "updatePanel";

            // Addd Controls to the UpdatePanel

            updatePanel.ContentTemplateContainer.Controls.Add(lblDateTime2);

            updatePanel.ContentTemplateContainer.Controls.Add(new LiteralControl("<br/>"));

            updatePanel.ContentTemplateContainer.Controls.Add(btnSend);

Die in das UpdatePanel überführten Steuerelemente müssen danach aus der Controls-Collection des Webparts entfernt und durch das UpdatePanel ersetzt werden.

protected override void CreateChildControls()

            base.CreateChildControls();

            this.Controls.Add(lblDateTime1);

            this.Controls.Add(new LiteralControl("<br/>"));

            this.Controls.Add(updatePanel);

Das war es auch schon. Der Webpart führt ab sofort ein partielles Rendering des Labels und des Buttons aus, was zur Folge hat, dass das erste Label den Zeitwert des ersten Aufrufs behält und das Zweite durch den Button partiell aktualisiert werden kann.

5. ProgressBar integrieren
Das UpdateProgress-Control liefert die Funktion, während der Ausführung des partiellen Renderings eine Statusinformation darzustellen. In welcher Art und Weise dieser Status dargestellt wird obliegt dem Entwickler / Designer, da das Control über ein Template beliebiges HTML render kann.

Als ProgressTemplate erwartet das UpdateProgress-Control eine Klasse, die ITemplate implementiert. In meinem Beispiel verwende ich eine einfache Template-Klasse, die das übergebene HTML bei der Ausführung der partiellen Anfrage auf die Ausgabe rendert.

public class ProgressTemplate : ITemplate

            private string template;

            public ProgressTemplate(string temp)

                template = temp;

            public void InstantiateIn(Control container)

                LiteralControl ltr = new LiteralControl(this.template);

                container.Controls.Add(ltr);

Im Anschluss muss der UpdateProgress dem UpdatePanel zugeordnet, sowie der Controls Collection des Webparts hinzugefügt werden und schon ist der Aktualisierungsprozess animiert.

protected override void OnInit(EventArgs e)

...

            // Init UpdateProgress

            string templateHTML = "<div><img alt=\"Bitte warten...\" src=\"/_layouts/images/kpiprogressbar.gif\"/>&nbsp;</div>";

            updateProgress = new UpdateProgress();

            updateProgress.ID = "updateProgress";

            updateProgress.AssociatedUpdatePanelID = updatePanel.ClientID;

            updateProgress.ProgressTemplate = new ProgressTemplate(templateHTML);

...

Auch wenn einige Dinge zu beachten sind ist es eigentlich nicht so aufwendig einen Webpart mit AJAX-Funktionen zu bereichern. Der Effekt beim Anwender gerechtfertigt den Aufwand in jedem Projekte.

Das komplette Visual Studio Projekt des Beispielwebparts kann hier heruntergeladen werden.