Lebenszyklusereignisse des ASP.NET AJAX-Clients

Übersetzung: Valens
Zeit: 11.06.2007
Originaltext: http://ajax.asp.net/docs/overview/AJAXClientEvents.aspx

Jeder ist willkommen, Kommentare abzugeben und ich werde aktiv Änderungen vornehmen!

Einführung [Einführung]

Microsoft Ajax schlägt clientseitige Lebenszyklusereignisse vor, die den serverseitigen Lebenszyklusereignissen von ASP.NET 2.0-Seiten ähneln. Diese clientseitigen Ereignisse ermöglichen es uns, unsere Benutzeroberfläche sowohl für herkömmliche Postbacks als auch für asynchrone Postbacks (teilweise Seitenaktualisierungen) anzupassen. Sie können Ihnen auch dabei helfen, benutzerdefinierte Skripte während des gesamten Seitenlebenszyklus zu verwalten und zu verwenden.

Diese clientseitigen Ereignisse werden in der AJAX-Libray-Klasse von Microsoft vorgeschlagen (wir finden sie in der AJAX-Libray-Klasse). Diese Klassen werden automatisch instanziiert (instanziiert?), wenn ein Serversteuerelement mit AJAX geladen wird. Diese Klassen stellen einige APIs bereit, damit wir Ereignisse an Ereignisanbieter-Handler binden können. Und die AJAX-Bibliothek ist browserunabhängig, sodass der von Ihnen geschriebene Code in allen unterstützten Browsern funktioniert.

Die wichtigsten Ereignisse sind das Ladeereignis der Anwendungsinstanz, das die Anforderung initiiert, und das asynchrone Postback. Wenn das Skript während des Load-Handler-Ereignisses ausgeführt wird, wurden alle Skripte und Komponenten geladen und sind verfügbar. Wenn ein Teil der Seite mithilfe des UpdatePanel-Steuerelements aktualisiert wird, ist die PageRequestManager-Klasse das kritischste aller Clientereignisse. Mit diesen clientseitigen Ereignissen können Sie bestimmte Szenarien umsetzen. Beispiele hierfür sind: Rückgängigmachen von Postbacks, Festlegen einer höheren Priorität für ein Postback und bessere Interaktion des UpdatePanels beim Aktualisieren.

Diese Ereignisse sind für uns sehr hilfreich, um Seiten zu erstellen oder Komponenten zu schreiben. Wenn Sie ein Webentwickler sind, können Sie benutzerdefinierte Skripte zum Laden und Entladen von Seiten verwenden.

serverseitigen

Lebenszyklusereignissen finden Sie unter „ASP.NET Page Life Cycle Overview“

in der Microsoft AJAX-Klassenbibliothek. Dort werden zwei Hauptklassen im Client-Lebenszyklus von AJAX-Webseiten vorgeschlagen. Anwendungsklasse und PageRequestManager-Klasse.

Die Application-Klasse wird instanziiert, wenn der Browser eine Seite anfordert, die ein ScriptManager-Steuerelement enthält. Die Application-Klasse ähnelt der serverseitigen Seitensteuerung. Sie erbt ebenfalls von der Control-Klasse, verfügt jedoch über einige zusätzliche Funktionen (im Vergleich zu serverseitigen Ereignissen). In ähnlicher Weise erbt die Anwendung die Klasse Sys.COmponent. Darüber hinaus stellt sie viele ausführbare Ereignisse während des Client-Lebenszyklus bereit.

Wenn eine Seite einen ScriptManager und ein oder mehrere UpdatePanel-Steuerelemente enthält, kann die Seite teilweise Aktualisierungseffekte erzielen. In diesem Fall steht dem Browser eine Instanz der PageRequestManager-Klasse zur Verfügung. Bei den von PageRequestManager bereitgestellten Clientereignissen dreht sich alles um asynchrones Postback.

Teilseiten

finden Sie unter: Übersicht über das Rendern von Teilseiten.

Fügen Sie nun Ereignisse hinzu oder entfernen Sie sie, indem Sie die Methoden add_eventname und reomve_eventname in den Klassen Application und PageRequestManager verwenden. Das folgende Beispiel zeigt, wie man einen Handler namens MyLoad zum Init-Ereignis des Application-Objekts hinzufügt.

Sys.Application.add_init(MyInit);
Funktion MyInit(sender) {
}
Sys.Appplication.remove_init(MyInit);

Comment; Dieses Beispiel zeigt nur die Syntax der Verwendung der Methoden add_eventname und remove_eventname. Weitere Einzelheiten zur Verwendung dieses Ereignisses finden Sie in einem späteren Thema.

Behandeln der Lade- und Entladeereignisse der Anwendung [Lade- und Entladeereignisse der Operationsanwendung]

Um die Lade- und Entladeereignisse des Anwendungsobjekts auszuführen, ist keine explizite Bindung an ein Operationsereignis erforderlich. Stattdessen können Sie eine Funktion direkt mit den reservierten Schlüsselwörtern pageLoad und pageUnload erstellen. Das folgende Beispiel zeigt, wie dem Ladeereignis der Anwendung eine Aktion hinzugefügt wird.

Funktion pageLoad(sender, args) {
}

Ereignisse für andere Client-Klassen [Andere Client-Klassen]

In diesem Thema werden nur Ereignisse beschrieben, die von den Klassen Application und PageRequestManager bereitgestellt werden. Die AJAX-Klassenbibliothek von Microsoft enthält außerdem die folgenden Klassen zum Hinzufügen, Löschen und Entfernen von DOM-Elementereignissen. Zu diesen Klassen gehören:

Es gibt die Methode Sys.UI.DomEvent.addHandler oder Kurzschrift $addHandler.

Es gibt die Methode Sys.UI.DomEvent.clearHandlers oder Kurzschrift $clearHandlers.

Es gibt die Methode Sys.UI.DomEvent.removeHandler oder Kurzschrift $ RemoveHandler.

Ereignisse, die von DOM-Prinzipien bereitgestellt werden, werden in diesem Thema nicht behandelt.

Client-Ereignisse der Klassen Application und PageRequestManager [Client-Ereignisse der Klassen Application und PageRequestManager]

Die folgende Tabelle listet die Client-Ereignisse der Klassen Application und PageRequestManager auf, die Sie in AJAX ASP.NET-Seiten verwenden können. Der Ablauf der Ereignisse wird in einem späteren Thema besprochen.

Ereignis
(Veranstaltungsname)
Beschreibung
(beschreiben)

initEvent
[Initialisierungsereignis]
Dieses Ereignis wird ausgelöst, nachdem alle Skripte geladen wurden und bevor Objekte erstellt werden. Wenn Sie planen, eine Komponente (ein Skript) zu schreiben, stellt das Init-Ereignis einen Punkt im Lebenszyklus bereit, an dem die Komponente (das Skript) zur Seite hinzugefügt werden kann. Diese Komponente kann von anderen Skripten im Lebenszyklus aufgerufen werden. Wenn Sie ein Webentwickler sind, wird in den meisten Fällen empfohlen, das Load-Ereignis anstelle des Init-Ereignisses zu verwenden.

Das Init-Ereignis wird nur einmal erstellt, wenn mit der Generierung der Seite begonnen wird. Nachfolgende teilweise Seitenaktualisierungen lösen das Init-Ereignis nicht aus.

Ladeereignis
[Ladeereignis]
Dieses Ereignis wird ausgelöst, nachdem alle Skripte geladen und alle mit $create initialisierten Programmobjekte erstellt wurden. Dieses Ereignis wird von allen Postbacks an den Server ausgelöst, einschließlich asynchroner Postbacks.

Wenn Sie ein Webentwickler sind, können Sie eine Funktion namens pageLoad erstellen, die vom Ladeereignis selbst bereitgestellt wird. Die pageLoad-Operation (Handler) kann nach jeder Operation aufgerufen werden, die über die Methode add_load zum Ladeereignis hinzugefügt wird.

Das Ladeereignis erfordert ein Sys.ApplicationLoadEventArgs-Objekt als eventargs-Parameter. Mit diesem Parameter können Sie entscheiden, ob auf der Seite eine Teilaktualisierung angezeigt werden muss, und Sie können auch entscheiden, welche Komponenten erstellt werden sollen, nachdem das letzte Ladeereignis ausgelöst wurde.

Ereignis entladen
[Deinstallationsereignis]
Wird ausgelöst, bevor alle Objekte freigegeben werden und bevor das window.unload-Ereignis des Browsers auftritt.

Sie können das Entladeereignis über eine Funktion namens pageUnload verarbeiten, die vom System selbst bereitgestellt wird. Das pageUnload-Ereignis wird aufgerufen, wenn die Seite im Browser entladen wird. Während dieses Ereignisses sollten wir alle vom Code belegten Ressourcen freigeben.

propertyChanged-Ereignis
[Attributänderungsereignis]
Wird ausgelöst, wenn sich die Eigenschaften einer Komponente ändern. Das Anwendungsobjekt erbt dieses Ereignis von der Component-Klasse. Dieses Ereignis wird nur ausgelöst, wenn der Entwickler beim Festlegen eines Eigenschaftswerts die Methode Sys.Component.raisePropertyChange aufruft.

Weitere Informationen finden Sie unter Definieren benutzerdefinierter Komponenteneigenschaften und Auslösen von PropertyChanged-Ereignissen.
Eigenschaftsänderungsereignisse erfordern ein Sys.applicationLoadEventArgs-Objekt als eventargs-Parameter.

Ereignis entsorgen
[Veröffentlichungsereignis]
Dieses Ereignis wird ausgelöst, wenn die Anwendungsinstanz freigegeben wird. Das Anwendungsobjekt erbt dieses Ereignis von der Component-Klasse.

initializeRequest-Ereignis
[Initialisierungsanforderungsereignis]
Dieses Ereignis tritt zu Beginn einer asynchronen Anforderung auf. Mit diesem Ereignis können Sie ein herkömmliches Postback abbrechen, um beispielsweise einem asynchronen Postback Vorrang zu geben.

Das Initialisierungsanforderungsereignis erfordert einen eventargs-Parameter, der vom Sys.WebForms.InitializeRequestEventArgs-Objekt bereitgestellt wird. Dieses Objekt stellt nützliche Elemente von Objekten bereit, die Postbacks und zugrunde liegende Anforderungen verursachen. Dieses Ereignis macht auch das Abbruchattribut verfügbar. Wenn Sie cancel auf true setzen, wird ein neues Postback abgebrochen.

beginRequest-Ereignis
[Anforderungsereignis starten]
Dieses Ereignis wird ausgelöst, bevor ein asynchrones Postback an den Server beginnt. Wenn bereits ein Postback-Prozess vorhanden ist, wird dieser gestoppt (mithilfe der abortPostBack-Methode). Sie können dieses Ereignis verwenden, um Anforderungsheader festzulegen oder eine interessante (Animations-)Eingabeaufforderung auf der Seite anzuzeigen, um anzuzeigen, dass die Anforderung ausgeführt wird.

Dieses Ereignis erfordert ein Sys.WebForms.BeginRequestEventArgs-Objekt als eventargs-Parameter. Dieses Objekt stellt nützliche Elemente zum Verursachen von Postbacks und zugrunde liegenden Anforderungsobjekten bereit.

pageLoading-Ereignis
[Seitenladeereignis]
Wird ausgelöst, bevor Inhalte auf der Seite aktualisiert werden, wenn ein asynchrones Postback vom Server empfangen wurde. Mit diesem Ereignis können Sie einen benutzerdefinierten Übergangseffekt für Inhalte bereitstellen, die aktualisiert werden müssen.

Dieses Ereignis erfordert ein Sys.WebForms.PageLoadingEventArgs-Objekt als eventargs-Parameter. Dieses Objekt stellt nützliche Informationen darüber bereit, welche Panels als Ergebnis des letzten asynchronen Postbacks gelöscht und aktualisiert werden.

pageLoaded-Ereignis
[Ereignis „Seitenladevorgang abgeschlossen“]
Wird ausgelöst, nachdem der gesamte Inhalt der Seite durch ein synchrones oder asynchrones Postback-Ergebnis aktualisiert wurde. Während des synchronen Postbacks können nur Panels erstellt werden, während beim asynchronen Postback Panels erstellt und aktualisiert werden können. Mit diesem Ereignis können Sie einen benutzerdefinierten Änderungseffekt für Inhalte verwalten, die aktualisiert werden müssen.

Dieses Ereignis erfordert ein Sys.WebForms.PageLoadedEventArgs-Objekt als eventargs-Parameter. Dieses Objekt stellt nützliche Informationen darüber bereit, welche Panels während des letzten Postbacks aktualisiert und erstellt wurden.

endRequest-Ereignis
[Anforderungsereignis beenden]
Wird ausgelöst, nachdem ein asynchrones Postback als Antwort abgeschlossen und die Seite aktualisiert wurde oder nachdem während der Anfrage ein Fehler aufgetreten ist. Tritt ein Fehler auf, wird die Seite nicht aktualisiert. Verwenden Sie dieses Ereignis, um Besuchern eine benutzerdefinierte Fehlermeldung bereitzustellen oder sich im Fehlerprotokoll anzumelden.

Dieses Ereignis erfordert ein Sys.WebForms.EndRequestEventArgs-Objekt als eventargs-Parameter. Dieses Objekt stellt einige nützliche Informationen über den ausgelösten Fehler bereit und gibt an, ob der Fehler behandelt wurde. Außerdem werden verfügbare Informationen zum entsprechenden Objekt bereitgestellt.

Beispiel für eine Ereignisreihenfolge [Beispiel für eine Ereignisreihenfolge]

Das folgende Beispiel zeigt, wie clientseitige Ereignisse auf einer Seite mit zwei verschachtelten UpdatePanel-Steuerelementen ausgelöst werden. Bitte beachten Sie den Unterschied zwischen dem Klicken auf die Schaltfläche im übergeordneten Bedienfeld und der Schaltfläche im eingebetteten Bedienfeld. Die Schaltfläche im übergeordneten Panel führt dazu, dass das übergeordnete Panel aktualisiert wird und das darin eingebettete Panel gelöscht und neu erstellt wird. Schaltflächen mit eingebetteten Panels bewirken nur Aktualisierungen des eingebetteten Panels.

Seitencode:

1<%@ Page Language="C#" %>
2
3<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
4 " http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd ">
5
6<script runat="server">
7
8</script>
9
10<html xmlns=" http://www.w3.org/1999/xhtml " >
11<head runat="server">
12 <title>Beispiel für ein Kundenereignis</title>
13 <style type="text/css">
14 #OuterPanel {Breite: 600px; Höhe: 200px; durchgehend blau;
15 #NestedPanel { width: 596px; height: 60px; border: 2px solid green;
16 Rand links: 5 Pixel; Rand rechts: 5 Pixel; Rand unten: 5 Pixel;
17 </style>
18</head>
19<Körper>
20 <form id="form1" runat="server">
21 <div>
22 <asp:ScriptManager ID="ScriptManager1" runat="server">
23 <Skripte>
24 <asp:ScriptReference Path="ClientEventTest.js" />
25 </Scripts>
26 </asp:ScriptManager>
27 <asp:UpdatePanel ID="OuterPanel" UpdateMode="Conditional" runat="server">
28 <ContentTemplate>
29 Postbacks von der Innenseite des Außenpaneels und des Innenpaneels sind
30 asynchrone Postbacks. PRM = Sys.WebForms.PageRequestManager APP = Sys.Application.
31
32 <br /><br />
33 <asp:Button ID="OPButton1" Text="Outer Panel Button" runat="server" />
34 Zuletzt aktualisiert am
35 <%= DateTime.Now.ToString() %>
36 <br /><br />
37
38 <asp:UpdatePanel ID="NestedPanel" UpdateMode="Conditional" runat="server">
39 <ContentTemplate>
40 <asp:Button ID="NPButton1" Text="Nested Panel 1 Button" runat="server" />
41 Zuletzt aktualisiert am
42 <%= DateTime.Now.ToString() %>
43 <br />
44 </ContentTemplate>
45 </asp:UpdatePanel>
46 </ContentTemplate>
47 </asp:UpdatePanel>
48
49 <input type="button" onclick="Clear();" value="Clear" />
50
51 <asp:Button ID="FullPostBack" runat="server" Text="Full Postback" />
52 <a href=" http://www.microsoft.com">Testfenster -Entladen</a>
53 <br />
54 <span id="ClientEvents"></span>
55 </div>
56 </form>
57</body>
58</html>
59

Skriptcode:

1// Anwendungs-Ereignishandler einbinden.
2var app = Sys.Application;
3app.add_load(ApplicationLoad);
4app.add_init(ApplicationInit);
5app.add_disposing(ApplicationDisposed);
6app.add_unload(ApplicationUnload);
7
8
9//Anwendungsereignishandler für Komponentenentwickler.
10function ApplicationInit(sender) {
11 var prm = Sys.WebForms.PageRequestManager.getInstance();
12 if (!prm.get_isInAsyncPostBack())
13 {
14 prm.add_initializeRequest(InitializeRequest);
15 prm.add_beginRequest(BeginRequest);
16 prm.add_pageLoading(PageLoading);
17 prm.add_pageLoaded(PageLoaded);
18 prm.add_endRequest(EndRequest);
19}
20 $get('ClientEvents').innerHTML += "APP:: Application init. <br/>";
einundzwanzig}
22function ApplicationLoad(sender, args) {
23 $get('ClientEvents').innerHTML += "APP:: Anwendungslast. ";
24 $get('ClientEvents').innerHTML += "(isPartialLoad = " + args.get_isPartialLoad() + ")<br/>";
25}
26function ApplicationUnload(sender) {
27 warning('APP::Application unload.');
28}
29function ApplicationDisposed(sender) {
30 $get('ClientEvents').innerHTML += "APP::Anwendung entsorgen. <br/>";
31
32}
33//Anwendungsereignishandler für Seitenentwickler.
34Funktion pageLoad() {
35 $get('ClientEvents').innerHTML += "PAGE:: Load.<br/>";
36}
37
38Funktion pageUnload() {
39 warning('Page:: Seite entladen.');
40}
41
42// PageRequestManager-Ereignishandler.
43function InitializeRequest(sender, args) {
44 $get('ClientEvents').innerHTML += "<hr/>";
45 $get('ClientEvents').innerHTML += "PRM:: Asynchrone Anfrage wird initialisiert.<br/>";
46}
47function BeginRequest(sender, args) {
48 $get('ClientEvents').innerHTML += "PRM:: Verarbeitung der asynchronen Anfrage beginnen.<br/>";
49}
50function PageLoading(sender, args) {
51 $get('ClientEvents').innerHTML += "PRM:: Ergebnisse der asynchronen Anfrage werden geladen.<br/>";
52 var updatePanels = printArray("PanelsUpdating", args.get_panelsUpdating());
53 var deletePanels = printArray("PanelsDeleting", args.get_panelsDeleting());
54
55 var message = "-->" + aktualisiertPanels + "<br/>-->" + gelöschtePanels + "<br/>";
56
57 document.getElementById("ClientEvents").innerHTML += message;
58}
59function PageLoaded(sender, args) {
60 $get('ClientEvents').innerHTML += "PRM:: Laden der Ergebnisse der asynchronen Anfrage abgeschlossen.<br/>";
61 var updatePanels = printArray("PanelsUpdated", args.get_panelsUpdated());
62 varcreatedPanels = printArray("PaneslCreated", args.get_panelsCreated());
63
64 var message = "-->" + aktualisiertPanels + "<br/>-->" + erstelltPanels + "<br/>";
65
66 document.getElementById("ClientEvents").innerHTML += message;
67}
68function EndRequest(sender, args) {
69 $get('ClientEvents').innerHTML += "PRM:: Ende der asynchronen Anfrage.<br/>";
70}
71
72// Hilfsfunktionen.
73functionClear()
74{
75 $get('ClientEvents').innerHTML = "";
76}
77Funktion printArray(name, arr)
78{
79 varpanels = name + '=' + arr.length;
80 if(arr. Länge > 0)
81 {
82 Tafeln += "(";
83 for(var i = 0; i < arr.length; i++)
84 {
85 Panels += arr[i].id + ',';
86}
87 Panels = Panels.substring(0, Panels.length - 1);
88 Tafeln += ")";
89 }
90 Rücklaufplatten;
91}
92

Ausführungseffekt Code anzeigen

Ereignisreihenfolge für häufige Szenarien [Allgemeine Ereignisreihenfolge]

Die Reihenfolge der Ereignisauslösung hängt immer noch davon ab, welche Steuerelemente auf der Seite verwendet werden und welche Art von Anforderung auftritt (Initialisierungsanforderung, herkömmliches Postback oder asynchrones Postback). In diesem Abschnitt wird die Ereignisanforderungssequenz für mehrere gängige Szenarien beschrieben.

Erstanforderung [Initialisierungsanforderung]

Während einer Seiteninitialisierungsanforderung wird eine kleine Anzahl von Clientereignissen ausgelöst. Gehen Sie davon aus, dass es sich bei der Initialisierungsanforderung um das folgende Szenario handelt.

· Die Seite enthält ein ScriptManager-Steuerelement und die Eigenschaften SupportsPartialRendering und EnablePartialRendering des Steuerelements sind beide wahr.
· Die Anfrage ist vom Typ GET;
· Der Server kann normal antworten.

Hier ist die Reihenfolge, in der Ereignisse auf der Clientseite auftreten:
1. Es erfolgt eine Initialisierungsanforderung an den Server.
2. Der Client erhält die Antwort.
3. Die Anwendungsinstanz löst das Init-Ereignis aus.
4. Die Anwendungsinstanz löst das Ladeereignis aus.

Das Initialisierungsereignis tritt während des gesamten Seitenlebenszyklus nur einmal auf, wenn die Anwendung instanziiert wird. Es wird nicht durch nachfolgende asynchrone Postbacks ausgelöst. Während der ersten Anfrage (beachten Sie die Anfrage) werden keine PageRequestManager-Ereignisse ausgelöst.

Asynchrones Postback [Asynchrones Postback]

Ein asynchrones Postback sendet einige Seitendaten an den Server, empfängt eine serverseitige Antwort und aktualisiert dann einen Teil der Seite. Nehmen Sie das folgende asynchrone Postback-Szenario an:

· Die Seite enthält ein ScriptManager-Steuerelement und die Eigenschaften „SupportsPartialRendering“ und „EnablePartialRendering“ des Steuerelements sind beide „true“.
· Es gibt ein UpdatePanel-Steuerelement auf der Seite und der Wert der ChildrenAsTriggers-Eigenschaft des Steuerelements wird in „true“ geändert.
· Im UpdatePanel gibt es eine Schaltfläche zum Auslösen eines asynchronen Postbacks.
· Erhalten Sie erfolgreich eine Antwort vom Server.

Hier ist die Reihenfolge, in der Ereignisse auf der Clientseite auftreten:
1. Wenn Sie auf die Schaltfläche im UpdatePanel-Steuerelement klicken, wird ein asynchrones Postback verursacht.
2. Die PageRequestManager-Instanz hat das initializeRequest-Ereignis ausgelöst.
3. Die PageRequestManager-Instanz hat das beginRequest-Ereignis ausgelöst.
4. Die Anfrage wird an den Server gesendet.
5. Der Client erhält die Antwort.
6. Die PageRequestManager-Instanz hat das pageLoading-Ereignis ausgelöst.
7. Die PageRequestManager-Instanz hat das pageLoaded-Ereignis ausgelöst.
8. Die Anwendungsinstanz hat das Ladeereignis ausgelöst.
9. Die PageRequestManager-Instanz hat das endRequest-Ereignis ausgelöst.

Bitte beachten Sie, dass das Ladeereignis der Anwendung nach dem pageLoaded-Ereignis des PageRequestManagers und vor dem endRequest-Ereignis liegt.

Mehrere asynchrone Postbacks [Mehrere asynchrone Postbacks]

Wenn eine vorherige Anfrage auf dem Server oder Browser ausgeführt wird und der Benutzer eine neue Anfrage sendet, treten mehrere asynchrone Postbacks auf. Gehen Sie davon aus, dass das folgende Szenario den Fall mehrerer asynchroner Postbacks beschreibt.

· Die Seite enthält ein ScriptManager-Steuerelement und die Eigenschaften SupportsPartialRendering und EnablePartialRendering des Steuerelements sind beide wahr.
· Die Seite enthält ein UpdatePanel-Steuerelement.
· Im UpdatePanel wird zweimal auf ein Schaltflächensteuerelement geklickt, das ein asynchrones Postback verursacht. Der zweite Klick erfolgt, während der Server die durch den ersten Klick initiierte Anfrage verarbeitet.
· Die Antwort auf die erste vom Server zurückgegebene Anfrage erhalten.

Hier ist die Reihenfolge, in der Ereignisse auf der Clientseite auftreten:
1. Durch Klicken auf die Schaltfläche im UpdatePanel wird ein asynchrones Postback ausgelöst.
2. Die PageRequestManager-Instanz hat das initializeRequest-Ereignis ausgelöst.
3. Die PageRequestManager-Instanz hat das beginRequest-Ereignis ausgelöst.
4. Die Anfrage wird an den Server gesendet.
5. Der Client erhält die Antwort.
6. Durch erneutes Klicken auf die Schaltfläche wird ein zweites asynchrones Postback ausgelöst.
7. Die PageRequestManager-Instanz löst das initializeRequest-Ereignis für den zweiten Klick aus.
8. Die PageRequestManager-Instanz löst das beginRequest-Ereignis für den zweiten Klick aus.
9. Die zweite Klickanfrage von Northern Expedition hat den Server gescannt.
10. Der Kunde erhält die Antwort des zweiten Klicks.
11. Die PageRequestManager-Instanz hat das pageLoading-Ereignis ausgelöst.
12. Die PageRequestManager-Instanz hat das pageLoaded-Ereignis ausgelöst.
13. Die Anwendungsinstanz hat das Ladeereignis ausgelöst.
14. Die PageRequestManager-Instanz hat das endRequest-Ereignis ausgelöst.

Das Standardverhalten des asynchronen Postbacks besteht darin, dass das neueste asynchrone Postback Vorrang hat. Wenn zwei asynchrone Postbacks nacheinander erfolgen und das erste asynchrone Postback noch vom Browser verarbeitet wird, wird das erste asynchrone Postback abgebrochen. Wenn das erste Postback an den Server gesendet wurde, gibt der Server die erste Anfrage erst zurück, wenn die zweite Anfrage eintrifft. Weitere Informationen zum Festlegen der Priorität für asynchrone Postbacks finden Sie unter „Vorrang für ein bestimmtes asynchrones Postback festlegen“.

Von einer Seite weg navigieren [Andere Seiten durchsuchen]

Wenn der Benutzer von einer Seite aus auf andere Seiten zugreift, wird die aktuelle Seite angezeigt Entladen Sie den Browser, sodass Sie das Entladeereignis ausführen können, um Ressourcen freizugeben. Angenommen, dieses Szenario wird unten simuliert.

· Die Seite enthält ein ScriptManager-Steuerelement und die Eigenschaften SupportsPartialRendering und EnablePartialRendering des Steuerelements sind beide wahr.
· Die Zielseite existiert.

Hier ist die Reihenfolge, in der Ereignisse auf der Clientseite auftreten:
1. Initiieren Sie eine Anfrage für eine neue Seite.
2. Der Browser erhält eine Antwort mit der Anforderung einer neuen Seite.
3. Die Anwendungsinstanz löst das Entladeereignis aus.
4. Eine neue Seite wird angezeigt.

Wenn beim Anfordern einer neuen Seite ein Fehler auftritt, wird das Unload-Ereignis trotzdem ausgelöst, die neue Seite wird jedoch nicht angezeigt.

【über】