Ereignismodell für ASP.NET-Webserversteuerelemente

  • Artikel

Aktualisiert: November 2007

Ein wichtiges Feature von ASP.NET ist die Möglichkeit, Webseiten mit einem ereignisbasierten Modell zu programmieren, wie es auch für Clientanwendungen verwendet wird. Ein einfaches Beispiel: Sie fügen einer ASP.NET-Webseite eine Schaltfläche hinzu und schreiben anschließend einen Ereignishandler für das Klickereignis der Schaltfläche. Dieses Vorgehen kennen wir zwar schon von Webseiten her, die ausschließlich mit Clientskript arbeiten (wobei das onclick-Ereignis mit dynamischem HTML behandelt wird). ASP.NET überträgt dieses Modell jedoch auf die serverbasierte Verarbeitung.

Durch ASP.NET-Serversteuerelemente ausgelöste Ereignisse unterscheiden sich geringfügig von Ereignissen in herkömmlichen HTML-Seiten oder clientbasierten Webanwendungen. Der Unterschied entsteht hauptsächlich durch die Trennung des Ereignisses selbst von der Stelle, wo das Ereignis behandelt wird. In clientbasierten Anwendungen werden Ereignisse auf dem Client ausgelöst und behandelt. In ASP.NET-Webseiten haben Ereignisse, die Serversteuerelementen zugeordnet sind, ihren Ursprung auf dem Client (Browser). Sie werden jedoch von der ASP.NET-Seite auf dem Webserver behandelt.

Für auf dem Client ausgelöste Ereignisse benötigt das Ereignismodell für ASP.NET-Websteuerelemente auf dem Client erfasste Ereignisinformationen sowie eine Ereignismeldung, die über HTTP Post an den Server übertragen wird. Die Seite muss die Meldung interpretieren, um festzustellen, welches Ereignis aufgetreten ist, und muss dann die entsprechende Methode im Code auf dem Server aufrufen, um das Ereignis zu behandeln.

ASP.NET behandelt alle Aufgaben, die beim Erfassen, Senden und Interpretieren des Ereignisses durchgeführt werden. Beim Erstellen von Ereignishandlern in einer ASP.NET-Webseite müssen Sie sich normalerweise nicht darum kümmern, wie die Ereignisinformationen erfasst und dem Code zur Verfügung gestellt werden. Stattdessen können Sie Ereignishandler wie in einem herkömmlichen Clientformular erstellen. Allerdings gibt es einige Aspekte bei der Ereignisbehandlung in ASP.NET-Webseiten, die Sie beachten sollten.

Ereignissatz für Serversteuerelemente und Seiten

Da die meisten ASP.NET-Serversteuerelementereignisse zur Verarbeitung einen Roundtrip zum Server erfordern, können sie die Leistung der Seite beeinträchtigen. Daher bieten Serversteuerelemente einen eingeschränkten Satz an Ereignissen, die normalerweise auf Klickereignisse beschränkt sind. Einige Serversteuerelemente unterstützen Änderungsereignisse. Zum Beispiel löst das CheckBox-Webserversteuerelement im Servercode ein CheckedChanged-Ereignis aus, wenn der Benutzer auf das Kontrollkästchen klickt. Einige Serversteuerelemente unterstützen abstraktere Ereignisse. Das Calendar-Webserversteuerelement z. B. löst ein SelectionChanged-Ereignis aus, das eine abstraktere Version des Klickereignisses ist.

Ereignisse, die häufig auftreten (und ohne das Wissen des Benutzers ausgelöst werden können), wie das onmouseover-Ereignis, werden von Serversteuerelementen nicht unterstützt. ASP.NET-Serversteuerelemente können für solche Ereignisse aber clientseitige Handler aufrufen. Dies wird weiter unten unter Ereignismodell für ASP.NET-Webserversteuerelemente erklärt.

Steuerelemente und die Seite selbst lösen bei jedem Verarbeitungsschritt ebenfalls Lebenszyklusereignisse aus, z. B. Init, Load und PreRender. Sie können diese Lebenszyklusereignisse in der Anwendung nutzen. Sie können zum Beispiel im Load-Ereignis einer Seite Standardwerte für Steuerelemente festlegen.

Ereignisargumente

Serverbasierte Ereignisse von ASP.NET-Seiten und -Steuerelementen folgen einem .NET Framework-Standardmuster für Ereignishandlermethoden. Alle Ereignisse übergeben zwei Argumente: ein Objekt, das das Ereignis auslösende Objekt darstellt, und ein Ereignisobjekt, das ereignisspezifische Informationen enthält. Das zweite Argument ist normalerweise vom Typ EventArgs, aber bei manchen Steuerelementen ist es von einem Typ, der für dieses Steuerelement spezifisch ist. Für ein ImageButton-Webserversteuerelement ist z. B. das zweite Argument vom Typ ImageClickEventArgs. Es enthält Informationen über die Koordinaten des Punkts, auf den der Benutzer geklickt hat.

Hinweis:

Ereignisse für Seiten (beispielsweise das Load-Ereignis der Seite) akzeptieren die beiden Standardargumente, in denen dann allerdings keine Werte übergeben werden.

Postbackereignisse und Nicht-Postbackereignisse in Serversteuerelementen

In Serversteuerelementen führen bestimmte Ereignisse (normalerweise Klickereignisse) dazu, dass die Seite unmittelbar an den Server zurückgesendet wird. Änderungsereignisse in HTML-Serversteuerelementen und Webserversteuerelementen, wie das TextBox-Steuerelement, verursachen kein sofortiges Postback. Stattdessen werden sie bei dem nächsten Postback ausgelöst.

Hinweis:

Falls dies vom Browser unterstützt wird, können Validierungssteuerelemente Benutzereingaben mit Clientskript prüfen – ohne einen Roundtrip zum Server. Ausführliche Informationen finden Sie unter Überprüfen der Benutzereingabe in ASP.NET-Webseiten.

Nach dem Zurücksenden der Seite werden die Initialisierungsereignisse der Seite (Page_Init und Page_Load) ausgelöst, und anschließend werden Steuerelementereignisse verarbeitet. Sie sollten keine Anwendungslogik erstellen, die von in einer bestimmten Reihenfolge ausgelösten Änderungsereignissen abhängt, es sei denn, Sie verfügen über fundierte Kenntnisse der Seitenereignisverarbeitung. Ausführliche Informationen finden Sie unter Übersicht über den Lebenszyklus von ASP.NET-Seiten.

Falls es für Ihre Anwendung sinnvoll ist, können Sie angeben, dass Änderungsereignisse einen Postback der Seite auslösen. Webserversteuerelemente, die ein Änderungsereignis unterstützen, enthalten eine AutoPostBack-Eigenschaft. Wenn diese Eigenschaft auf true festgelegt wurde, löst das Änderungsereignis des Steuerelements sofort ein Postback der Seite aus, ohne dass auf ein Klickereignis gewartet wird. Das CheckedChanged-Ereignis eines CheckBox-Steuerelements löst z. B. standardmäßig keine Übermittlung der Seite aus. Wenn Sie aber die AutoPostBack-Eigenschaft des Steuerelements auf true festlegen, wird die Seite zur Verarbeitung an den Server gesendet, sobald ein Benutzer auf das Kontrollkästchen klickt.

Hinweis:

Damit die AutoPostBack-Eigenschaft ordnungsgemäß funktioniert, muss der Browser des Benutzers Skripts zulassen. Meistens ist das die Standardeinstellung. Allerdings deaktivieren manche Benutzer Skripts aus Sicherheitsgründen. Ausführliche Informationen finden Sie unter Clientskript in ASP.NET-Webseiten.

Weitergeleitete Ereignisse

Webserversteuerelemente wie Repeater, DataList, GridView, FormView und DetailsView können Schaltflächensteuerelemente enthalten, die selbst Ereignisse auslösen. Jede Zeile in einem GridView-Steuerelement kann beispielsweise Schaltflächen enthalten, die dynamisch aus Vorlagen erstellt werden.

Damit nicht jede einzelne Schaltfläche ein eigenes Ereignis auslöst, werden die Ereignisse der geschachtelten Steuerelemente an das Containersteuerelement weitergeleitet. Der Container wiederum löst ein generisches ItemCommand-Ereignis aus, an dessen Parametern zu erkennen ist, welches Steuerelement das ursprüngliche Ereignis ausgelöst hat. Sie brauchen keine individuellen Ereignishandler für untergeordnete Steuerelemente mehr zu schreiben, wenn Sie auf dieses einzelne Ereignis reagieren.

Das ItemCommand-Ereignis enthält zwei standardmäßige Ereignisargumente: ein Objekt, das auf die Quelle des Ereignisses verweist, und ein Ereignisobjekt, das ereignisspezifische Informationen enthält.

Hinweis:

Das GridView-Steuerelement, das DataList-Steuerelement und andere Datensteuerelemente unterstützen zusätzliche Ereignisse, wie EditCommand, DeleteCommand und UpdateCommand, bei denen es sich um Sonderfälle weitergeleiteter Ereignisse handelt.

Bei Schaltflächen können Sie die CommandArgument-Eigenschaft verwenden, um eine benutzerdefinierte Zeichenfolge an den Ereignishandler zu übergeben, damit Sie wissen, welche Schaltfläche das Ereignis ausgelöst hat. In einem DataList-Steuerelement lösen Schaltflächen beispielsweise das ItemCommand-Ereignis aus. Sie können die CommandArgument-Eigenschaft jeder Schaltfläche auf einen anderen Wert festlegen. So könnten Sie z. B. den Wert einer Schaltfläche auf "ShowDetails" und den Wert einer anderen Schaltfläche auf "AddToShoppingCart" festlegen und diese Werte später im Ereignishandler erfassen.

Binden von Ereignissen an Methoden

Ein Ereignis ist eine Meldung in der Art von "es wurde auf eine Schaltfläche geklickt". Im Code Ihrer Anwendung muss die Meldung in einen Methodenaufruf umgesetzt werden. Das Herstellen einer Verbindung zwischen der Ereignismeldung und einer spezifischen Methode, also eines Ereignishandlers, erfolgt mithilfe eines Ereignisdelegaten. Weitere Informationen finden Sie unter Ereignisse und Delegaten.

In ASP.NET Webseiten müssen Delegaten nicht explizit codiert werden, wenn das Steuerelement auf der Seite deklarativ (in Markup) erstellt wurde. Es gibt verschiedene Möglichkeiten, die Ereignisbindung umzusetzen. Diese hängen von der Art des Ereignisses und der verwendeten Programmiersprache ab. Ausführliche Informationen finden Sie unter Gewusst wie: Erstellen von Ereignishandlern für ASP.NET-Webseiten.

Bindung von Steuerelementereignissen

Bei in der Seite deklarierte Steuerelementen können Sie ein Ereignis an eine Methode binden, indem Sie im Markup des Steuerelements ein Attribut (Eigenschaft) festlegen. Das folgende Codebeispiel zeigt, wie das Click-Ereignis eines ASP.NET-Button-Steuerelements an eine Methode mit dem Namen ButtonClick gebunden werden kann.

<asp:button id="SampleButton"  
   text="Submit" onclick="ButtonClick" />

Beim Kompilieren der Seite sucht ASP.NET nach einer Methode mit dem Namen ButtonClick und bestätigt, dass die Methode die entsprechende Signatur besitzt (zwei Argumente werden akzeptiert: eines vom Typ Object und das andere vom Typ EventArgs). Daraufhin bindet ASP.NET das Ereignis automatisch an die Methode.

In Visual Basic kann zum Binden von Ereignissen an Methoden auch das Handles-Schlüsselwort in der Ereignishandlerdeklaration verwendet werden, wie im folgenden Codebeispiel gezeigt:

Private Sub ButtonClick(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles SampleButton.Click

Binden von Seitenereignissen

ASP.NET-Seiten lösen Lebenszyklusereignisse wie Init, Load, PreRender usw. aus. Standardmäßig können Seitenereignisse mithilfe der Namenskonvention Page_Ereignisname an Methoden gebunden werden. Zum Erstellen eines Handlers für das Load-Ereignis der Seite können Sie beispielsweise eine Methode mit dem Namen Page_Load erstellen. Während der Kompilierung findet ASP.NET Methoden, die auf dieser Namenskonvention basieren und führt automatisch die Bindung zwischen Ereignis und Methode aus. Sie können die Konvention Page_Ereignisname für jedes Ereignis verwenden, das durch die Page-Klasse offengelegt wird.

Hinweis:

Methoden zur Behandlung von Seitenereignissen erfordern keine Argumente.

Wenn Sie es vorziehen, können Sie Handler auch explizit erstellen. Das automatische Binden von Seitenereignissen basierend auf der Namenskonvention für Methoden wird durch eine Seiteneigenschaft mit dem Namen AutoEventWireup gesteuert. Diese Eigenschaft ist standardmäßig auf true festgelegt, sodass Suche und Bindung von ASP.NET automatisch ausgeführt werden, wie oben beschrieben. Stattdessen können Sie diese Eigenschaft auch auf false festlegen, indem Sie das AutoEventWireup=false-Attribut in der @ Page-Direktive hinzufügen. Sie können dann Methoden mit beliebigem Namen erstellen und explizit an Seitenereignisse binden. In Visual Basic können Sie das Handles-Schlüsselwort verwenden, wie im folgenden Codebeispiel gezeigt:

Sub MyPageLoad(sender As Object, e As EventArgs) Handles MyBase.Load

Der Nachteil des AutoEventWireup-Attributs ist der, dass die Handler für Seitenereignisse spezifische, vorhersagbare Namen haben müssen. Dies schränkt die Flexibilität bei der Benennung von Ereignishandlern ein.

Hinweis:

Wenn Sie explizites Binden für Seitenereignisse verwenden, muss die AutoEventWireup-Eigenschaft auf false festgelegt sein, damit die Methode nicht versehentlich zweimal aufgerufen wird.

Explizite Bindung für dynamische Steuerelemente

Ereignisse von Steuerelementen, die durch Deklaration im Markup erstellt wurden, können mithilfe eines Attributs (z. B. onclick) oder in Visual Basic mit dem Handles-Schlüsselwort an Methoden gebunden werden. Bei dynamisch (in Code) erstellten Steuerelementen kann keine dieser Methoden verwendet werden, weil der Compiler zum Zeitpunkt der Kompilierung keinen Verweis auf das Steuerelement hat.

In diesem Fall müssen Sie explizite Ereignisbindung verwenden. In Visual Basic kann die AddHandler-Anweisung verwendet werden, um ein Ereignis in einem dynamisch erstellten Steuerelement an eine vorhandene Methode zu binden. In C# erstellen Sie einen Delegaten und ordnen ihn dem Ereignis des Steuerelements zu. Das folgende Codebeispiel zeigt, wie eine Methode mit dem Namen ButtonClick an ein Click-Ereignis einer Schaltfläche gebunden werden kann:

Dim b As New Button
b.Text = "Click"
AddHandler b.Click, AddressOf ButtonClick
Placeholder1.Controls.Add(b)

Button b = new Button;
b.Text = "Click";
b.Click += new System.EventHandler(ButtonClick);
Placeholder1.Controls.Add(b);

Reagieren auf Client- und Serverereignisse in ASP.NET-Serversteuerelementen

In diesem Thema wurde erläutert, wie Sie mit Ereignisse arbeiten, die in Servercode ausgelöst werden. Elemente, die von Steuerelementen an den Browser ausgegeben werden, können ihrerseits clientseitige Ereignisse auslösen, die in Clientskript behandelt werden können. Mit Clientskript können Sie den ASP.NET-Serversteuerelementen Maus- und Tastaturereignisbehandlung hinzufügen. Weitere Informationen finden Sie unter Clientskript in ASP.NET-Webseiten und Gewusst wie: Hinzufügen von Clientskriptereignissen zu ASP.NET-Webserversteuerelementen.

Anwendungs- und Sitzungsereignisse

Zusätzlich zu Seiten- und Steuerelementereignissen bietet ASP.NET Möglichkeiten zum Arbeiten mit Lebenszyklusereignissen, die ausgelöst werden, wenn die Anwendung gestartet oder beendet wird (Anwendungsereignisse) oder wenn die Sitzung eines einzelnen Benutzers gestartet oder beendet wird (Sitzungsereignisse):

  • Anwendungsereignisse werden für alle Anforderungen einer Anwendung ausgelöst. Zum Beispiel wird das BeginRequest-Ereignis des HttpApplication-Objekts (Application_BeginRequest) ausgelöst, wenn eine ASP.NET-Webseite oder ein XML-Webdienst in der Anwendung angefordert wird. Mit diesem Ereignis können Sie Ressourcen initialisieren, die für die Anforderungen an die Anwendung verwendet werden. Ein entsprechendes Ereignis, das EndRequest-Ereignis des HttpApplication-Objekts (Application_EndRequest), gibt Ihnen die Möglichkeit, für die Anforderung verwendete Ressourcen zu schließen oder freizugeben.

  • Sitzungsereignisse ähneln Anwendungsereignissen (es gibt ein Start-Ereignis und ein End-Ereignis). Sie werden jedoch für jede einzelne Sitzung innerhalb der Anwendung ausgelöst. Eine Sitzung beginnt, wenn ein Benutzer eine Seite zum ersten Mal von der Anwendung anfordert, und endet, wenn die Anwendung die Sitzung explizit schließt oder wenn die Sitzung das Zeitlimit überschreitet.

    Hinweis:

    Das Session_End-Ereignis wird nicht unter allen Umständen ausgelöst. Ausführliche Informationen finden Sie unter End.

Sie können in der Datei Global.asax Handler für diese Ereignistypen erstellen. Ausführliche Informationen zu diesem Thema finden Sie unter Übersicht über den Lebenszyklus von ASP.NET-Anwendungen für IIS 5.0 und 6.0 und Syntax von "Global.asax".

Siehe auch

Konzepte

Übersicht über die ASP.NET-Zustandsverwaltung

Weitere Ressourcen

Gewusst wie: Erstellen von Ereignishandlern für ASP.NET-Webseiten

Serverereignisbehandlung auf ASP.NET-Webseiten