Clientseitige Programmierung mittels WPSC
Letzte Änderung: Freitag, 30. Mai 2008
Gilt für: SharePoint Foundation 2010
Inhalt dieses Artikels
Namenskonflikte
Verwenden von Token
Verweisen auf Webparts mithilfe von "varPart" und "WebPart"
Elementverweise in einem Formular
Web Part Page Services Component (WPSC) ist ein Objektmodell, mit dessen Hilfe Sie Skripts für eine Webpartseite und die enthaltenen Webparts erstellen können. Wenn der Client erstmalig auf eine Webpartseite zugreift, wird die WPSC-Komponente zum Clientcomputer hinzugefügt. Die Komponente gilt für Webparts, die von der Microsoft.SharePoint.WebPartPages.WebPart-Klasse abgeleitet sind, jedoch nicht für Webparts, die von der ASP.NET-Klasse System.Web.UI.WebControls.WebParts.WebPart abgeleitet sind.
Namenskonflikte
Wenn Sie Skripts mithilfe von WPSC erstellen, sollten Sie eindeutige Namespaces oder Token verwenden, um Namenskonflikte zu vermeiden. Sie können Namespaces oder Token für Webpartereignisse, -namen, -meldungen und -statusangaben verwenden, um das Risiko für das Auftreten von Namenskonflikten zu beseitigen. Sie können außerdem Variablen und Elemente verwenden, die vom SharePoint Foundation-Webpart bereitgestellt werden, wenn die Seite gerendert wird.
Verwenden von Token
Token sind Platzhalter für Werte, die zur Laufzeit bestimmt werden können. Sie können vordefinierte Token an benannte Entitäten im Code anfügen, um die Skripterstellung zu vereinfachen und Namenskonflikte zu vermeiden. Zur Renderzeit werden die Token von der SharePoint Foundation-Webpartinfrastruktur durch Werte ersetzt, bis alle Token für die Seite ersetzt sind. Bei Token muss die Groß- und Kleinschreibung nicht beachtet werden, und sie können an einer beliebigen Position im Namen (also als Präfix, Suffix oder auch in der Mitte einer Variablen) verwendet werden.
Das Ersetzen von Token ist eine der besser geeigneten Strategien zur Vermeidung von Namenskonflikten. Zur Entwurfszeit fügen Sie ein Token zu Webpartnamen, eingebetteten Inhalten oder verknüpften Inhalten hinzu. Zur Laufzeit ersetzt die Webpartinfrastruktur das Token durch einen generierten Wert, der die eindeutige Benennung des fraglichen Elements sicherstellt. Sie können beispielsweise _WPQ_ als Präfix für HTML-IDs und Funktionsnamen einschließen. Zur Renderzeit konvertiert die Webpartinfrastruktur diese Literalzeichenfolge in die WebPartQualifier-Eigenschaft.
In der folgenden Tabelle sind die vordefinierten Token in alphabetischer Reihenfolge aufgeführt.
Tokenname |
Ersatzwert |
---|---|
_LogonUser_ |
Wert der von Request.ServerVariables("LOGON_USER") einer ASPX-Seite abgerufen wird. Dieser Wert enthält normalerweise die Domäne und den Benutzernamen des Clients und kann zur Benutzeridentifikation innerhalb eines Intranets verwendet werden. |
_WPID_ |
Die GUID einer Webpartinstanz im g_-Format, beispielsweise g_632c887a_20ba_4e6d_98eb_7404ee4841f. Dieses Token stellt eine eindeutige ID innerhalb der Seite bereit. |
_WPQ_ |
Die eindeutige ID eines Webparts innerhalb einer Webpartseite. Mit diesem Token können Sie HTML-IDs und Skriptfunktionsnamen auszeichnen, um Namenskonflikte zu vermeiden. |
_WPR_ |
Die URL des Ressourcenordners für das Webpart auf dem Server, nicht auf dem Client. |
Verweisen auf Webparts mithilfe von "varPart" und "WebPart"
Wenn eine Webpartseite gerendert wird, werden Webparts durch den WebPartPage-Webdienst Variablen und Element-IDs zugewiesen. Wenn Sie diese Variablen und Element-IDs in Kombination mit Token in einem clientseitigen Skript verwenden, können erreichen, dass Webparts auf sich selbst verweisen.
varPart
Gegen Ende des Ladens der Webpartseite wird jedem Webpart auf der Webpartseite eine Variable (beispielsweise varPartWPQ1) zugewiesen. Diese Variable verweist auf das WPSC-Part-Objekt für das Webpart. Ein Webpart kann diese Variable verwenden, um in eingebettetem Inhalt mithilfe des _WPQ_-Tokens auf sich selbst zu verweisen. Auch wenn die Hardcodierung der Variablen möglich ist (Sie können beispielsweise im Code auf varPartWPQ2 anstatt auf varPart_WPQ_ verweisen), kann es zu Problemen kommen, wenn sich der Webpartqualifizierer ändert. Es ist nicht sichergestellt, dass der Webpartqualifizierer derselbe bleibt, wenn sich die Webpartseite ändert. Das Hinzufügen und Umbenennen von Webparts kann sich auf die Reihenfolge der Webparts im Speicher auswirken, was sich wiederum auf den Webpartqualifizierer und den Wert, der durch das _WPQ_-Token dargestellt wird, auswirken kann. Es empfiehlt sich, sofern möglich, das _WPQ_-Token zu verwenden.
WebPart
Wenn die Webpartseite geladen wird, wird das Webpart auf der Seite als DIV-Element gerendert. Dieses Element erhält eine ID durch die Webpartinfrastruktur (beispielsweise WebPartWPQ1). Mit dieser ID können Sie das HTML-DOM für das Webpart bearbeiten, indem Sie WebPart mit dem _WPQ_-Token kombinieren. Auf diese Weise kann das Webpart mithilfe von WebPart_WPQ_ auf seine eigene HTML-Struktur verweisen. Bei der Bearbeitung des HTML-DOM einer Webpartseite ist Sorgfalt erforderlich. Änderungen an der DOM-Struktur des Webparts oder der Webpartseite selbst können sich auf das Verhalten des Browsers auswirken. Die sicherste und gängigste Verwendung von WebPart_WPQ_ besteht darin, die InnerHTML-Eigenschaft für das Webpart oder für Elemente innerhalb des Webparts zu bearbeiten. Mithilfe von Skripts können Sie InnerHTML mit skriptgenerierten Daten aktualisieren.
Elementverweise in einem Formular
Alle Webparts in einer Webpartseite sind Teil eines Formulars, da Webpartseiten im Grunde ASPX-Seiten sind. Für HTML muss jedes Element in einem Formular mit einem Formular-ID-Präfix versehen oder mittels document.all referenziert werden. Im Folgenden ist ein kurzes Beispiel aufgeführt:
<form id="MyForm">
<input type="text" id="MyText">
<input type="button" id="MyButton" onclick="buttonClicked">
<script>
function buttonClicked()
{
MyForm.MyText.value="Hello World!";
}
</script>
</form>
Alternativ dazu kann die Codezeile dieser Funktion auch folgendermaßen lauten:
document.all("MyText").value="Hello World!";
Jede dieser beiden Optionen ist zulässig.
![]() |
---|
Dieser Aspekt spielt nur eine Rolle, wenn ein <INPUT>-Tag verwendet wird. |
Siehe auch
Konzepte
Unterstützung für Standardsystemereignisse