Das ASP.NET 2.0-Seitenmodell
von Microsoft
In ASP.NET 1.x hatten Entwickler die Wahl zwischen einem Inlinecodemodell und einem CodeBehind-Codemodell. CodeBehind kann entweder mithilfe des Src-Attributs oder des CodeBehind-Attributs der @Page -Direktive implementiert werden. In ASP.NET 2.0 haben Entwickler weiterhin die Wahl zwischen Inlinecode und CodeBehind, aber das CodeBehind-Modell wurde erheblich verbessert.
In ASP.NET 1.x hatten Entwickler die Wahl zwischen einem Inlinecodemodell und einem CodeBehind-Codemodell. CodeBehind kann entweder mithilfe des Src-Attributs oder des CodeBehind-Attributs der @Page -Direktive implementiert werden. In ASP.NET 2.0 haben Entwickler weiterhin die Wahl zwischen Inlinecode und CodeBehind, aber das CodeBehind-Modell wurde erheblich verbessert.
Verbesserungen am Code-Behind-Modell
Um die Änderungen im CodeBehind-Modell in ASP.NET 2.0 vollständig zu verstehen, empfiehlt es sich, das Modell schnell so zu überprüfen, wie es in ASP.NET 1.x vorhanden war.
Das Code-Behind-Modell in ASP.NET 1.x
In ASP.NET 1.x bestand das CodeBehind-Modell aus einer ASPX-Datei (webform) und einer CodeBehind-Datei, die Programmiercode enthielt. Die beiden Dateien wurden mithilfe der @Page -Direktive in der ASPX-Datei verbunden. Jedes Steuerelement auf der ASPX-Seite verfügte in der CodeBehind-Datei über eine entsprechende Deklaration als instance Variable. Die CodeBehind-Datei enthielt auch Code für die Ereignisbindung und generierten Code, der für den Visual Studio-Designer erforderlich ist. Dieses Modell funktionierte recht gut, aber da jedes ASP.NET-Element auf der ASPX-Seite entsprechenden Code in der CodeBehind-Datei erforderte, gab es keine echte Trennung von Code und Inhalt. Wenn beispielsweise ein Designer einer ASPX-Datei außerhalb der Visual Studio-IDE ein neues Serversteuerelement hinzugefügt hat, würde die Anwendung aufgrund fehlender Deklaration für dieses Steuerelement in der CodeBehind-Datei unterbrochen.
Das Code-Behind-Modell in ASP.NET 2.0
ASP.NET 2.0 verbessert dieses Modell erheblich. In ASP.NET 2.0 wird CodeBehind mithilfe der neuen partiellen Klassen implementiert, die in ASP.NET 2.0 bereitgestellt werden. Die CodeBehind-Klasse in ASP.NET 2.0 ist als partielle Klasse definiert, was bedeutet, dass sie nur einen Teil der Klassendefinition enthält. Der verbleibende Teil der Klassendefinition wird dynamisch von ASP.NET 2.0 mithilfe der ASPX-Seite zur Laufzeit oder beim Vorkompilieren der Website generiert. Der Link zwischen der CodeBehind-Datei und der ASPX-Seite wird weiterhin mithilfe der @Page-Direktive hergestellt. Anstelle eines CodeBehind- oder Src-Attributs verwendet ASP.NET 2.0 jetzt jedoch das CodeFile-Attribut. Das Inherits-Attribut wird auch verwendet, um den Klassennamen für die Seite anzugeben.
Eine typische @Page-Direktive könnte wie folgt aussehen:
<%@Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>
Eine typische Klassendefinition in einer ASP.NET 2.0-CodeBehind-Datei könnte wie folgt aussehen:
public partial class _Default : System.Web.UI.Page
Hinweis
C# und Visual Basic sind die einzigen verwalteten Sprachen, die derzeit partielle Klassen unterstützen. Daher können Entwickler, die J# verwenden, das CodeBehind-Modell in ASP.NET 2.0 nicht verwenden.
Das neue Modell verbessert das CodeBehind-Modell, da Entwickler jetzt über Codedateien verfügen, die nur den code enthalten, den sie erstellt haben. Außerdem wird eine echte Trennung von Code und Inhalt ermöglicht, da in der CodeBehind-Datei keine instance Variablendeklarationen vorhanden sind.
Hinweis
Da die partielle Klasse für die ASPX-Seite die Ereignisbindung ist, können Visual Basic-Entwickler eine leichte Leistungssteigerung erzielen, indem sie die Handles-Schlüsselwort (keyword) in CodeBehind verwenden, um Ereignisse zu binden. C# verfügt über keine gleichwertige Schlüsselwort (keyword).
Neue @ Page-Direktivenattribute
ASP.NET 2.0 fügt der @Page-Direktive viele neue Attribute hinzu. Die folgenden Attribute sind in ASP.NET 2.0 neu.
Async
Mit dem Async-Attribut können Sie eine Seite konfigurieren, die asynchron ausgeführt werden soll. Behandeln Sie asynchrone Seiten weiter unten in diesem Modul.
Asynchrones Timeout
Gibt das Timeout für asynchrone Seiten an. Der Standardwert ist 45 Sekunden.
Codefile
Das CodeFile-Attribut ist der Ersatz für das CodeBehind-Attribut in Visual Studio 2002/2003.
CodeFileBaseClass
Das CodeFileBaseClass-Attribut wird in Fällen verwendet, in denen mehrere Seiten von einer einzelnen Basisklasse abgeleitet werden sollen. Aufgrund der Implementierung partieller Klassen in ASP.NET würde ohne dieses Attribut eine Basisklasse, die freigegebene allgemeine Felder verwendet, um auf steuerelemente zu verweisen, die auf einer ASPX-Seite deklariert wurden, aufgrund von ASP nicht ordnungsgemäß funktionieren. Die NETs-Kompilierungs-Engine erstellt automatisch neue Member basierend auf Steuerelementen auf der Seite. Wenn Sie daher eine gemeinsame Basisklasse für zwei oder mehr Seiten in ASP.NET möchten, müssen Sie die Basisklasse im CodeFileBaseClass-Attribut definieren und dann jede Seitenklasse von dieser Basisklasse ableiten. Das CodeFile-Attribut ist auch erforderlich, wenn dieses Attribut verwendet wird.
Compilationmode
Mit diesem Attribut können Sie die CompilationMode-Eigenschaft der ASPX-Seite festlegen. Die CompilationMode-Eigenschaft ist eine Enumeration, die die Werte Always, Auto und Never enthält. Der Standardwert ist Always. Die Einstellung Auto verhindert, dass ASP.NET die Seite nach Möglichkeit dynamisch kompilieren. Das Ausschließen von Seiten aus der dynamischen Kompilierung erhöht die Leistung. Wenn jedoch eine ausgeschlossene Seite diesen Code enthält, der kompiliert werden muss, wird beim Durchsuchen der Seite ein Fehler ausgelöst.
Aktivieren der Ereignisüberprüfung
Dieses Attribut gibt an, ob Postback- und Rückrufereignisse überprüft werden. Wenn dies aktiviert ist, werden Argumente für Postback- oder Rückrufereignisse überprüft, um sicherzustellen, dass sie vom Serversteuerelement stammen, das sie ursprünglich gerendert hat.
Aktivieren von Design
Dieses Attribut gibt an, ob ASP.NET Designs auf einer Seite verwendet werden. Der Standardwert ist FALSE. ASP.NET Themen werden in Modul 10 behandelt.
LinePragmas
Dieses Attribut gibt an, ob zeilenspezifische Pragmas während der Kompilierung hinzugefügt werden sollen. Linien pragmas sind Optionen, die von Debuggern zum Markieren bestimmter Codeabschnitte verwendet werden.
MaintainScrollPositionOnPostback
Dieses Attribut gibt an, ob JavaScript in die Seite eingefügt wird, um die Scrollposition zwischen Postbacks beizubehalten. Dieses Attribut ist standardmäßig false .
Wenn dieses Attribut true ist, fügt ASP.NET einen <Skriptblock> für das Postback hinzu, der wie folgt aussieht:
<script src="/website/WebResource.axd?d=jBAvpwrdOM_V_Xzeox989A2 &t=632653133849531250" type="text/javascript"> </script>
Beachten Sie, dass der src für diesen Skriptblock WebResource.axd ist. Diese Ressource ist kein physischer Pfad. Wenn dieses Skript angefordert wird, erstellt ASP.NET das Skript dynamisch.
Masterpagefile
Dieses Attribut gibt die master Seitendatei für die aktuelle Seite an. Der Pfad kann relativ oder absolut sein. Gestaltungsvorlagen werden in Modul 4 behandelt.
Stylesheetdesign
Mit diesem Attribut können Sie Die Darstellungseigenschaften der Benutzeroberfläche überschreiben, die von einem ASP.NET 2.0-Design definiert werden. Themen werden in Modul 10 behandelt.
Designwert
Gibt das Design für die Seite an. Wenn kein Wert für das StyleSheetTheme-Attribut angegeben wird, überschreibt das Theme-Attribut alle Stile, die auf Steuerelemente auf der Seite angewendet werden.
Title-Wert
Legt den Titel für die Seite fest. Der hier angegebene Wert wird im <title-Element> der gerenderten Seite angezeigt.
Viewstateencryptionmode
Legt den Wert für die ViewStateEncryptionMode-Enumeration fest. Die verfügbaren Werte sind Always, Auto und Never. Der Standardwert ist Auto. Wenn dieses Attribut auf den Wert Auto festgelegt ist, wird viewstate verschlüsselt. Ein Steuerelement fordert es an, indem die RegisterRequiresViewStateEncryption-Methode aufgerufen wird.
Festlegen öffentlicher Eigenschaftswerte über die @Page-Direktive
Eine weitere neue Funktion der @ Page-Direktive in ASP.NET 2.0 ist die Möglichkeit, den Anfangswert öffentlicher Eigenschaften einer Basisklasse festzulegen. Angenommen, Sie verfügen in Ihrer Basisklasse über eine öffentliche Eigenschaft namens SomeText , die beim Laden einer Seite in Hello initialisiert werden soll. Sie können dies erreichen, indem Sie einfach den Wert in der @ Page-Direktive wie folgt festlegen:
<%@Page Language="C#" SomeText="Hello!" Inherits="PageBase" %>
Das SomeText-Attribut der @ Page-Direktive legt den Anfangswert der SomeText-Eigenschaft in der Basisklasse auf Hello! fest. Das folgende Video zeigt eine exemplarische Vorgehensweise zum Festlegen des Anfangswerts einer öffentlichen Eigenschaft in einer Basisklasse mithilfe der @ Page-Direktive.
Neue öffentliche Eigenschaften der Page-Klasse
Die folgenden öffentlichen Eigenschaften sind in ASP.NET 2.0 neu.
Apprelativetemplatesourcedirectory
Gibt den anwendungsrelativen Pfad zur Seite oder zum Steuerelement zurück. Für eine Seite, die sich unter http://app/folder/page.aspxbefindet, gibt die -Eigenschaft beispielsweise ~/folder/zurück.
AppRelativeVirtualPath
Gibt den relativen pfad des virtuellen Verzeichnisses zur Seite oder zum Steuerelement zurück. Für eine Seite unter http://app/folder/page.aspxgibt die -Eigenschaft beispielsweise ~/folder/page.aspx zurück.
AsyncTimeout
Ruft das timeout ab, das für die asynchrone Seitenbehandlung verwendet wird, oder legt dieses fest. (Asynchrone Seiten werden später in diesem Modul behandelt.)
ClientQueryString
Eine schreibgeschützte Eigenschaft, die den Abfragezeichenfolgenteil der angeforderten URL zurückgibt. Dieser Wert ist URL-codiert. Sie können die UrlDecode-Methode der HttpServerUtility-Klasse verwenden, um sie zu decodieren.
Clientscript
Diese Eigenschaft gibt ein ClientScriptManager-Objekt zurück, das zum Verwalten von ASP verwendet werden kann. NETs-Emission des clientseitigen Skripts. (Die ClientScriptManager-Klasse wird später in diesem Modul behandelt.)
EnableEventValidation
Diese Eigenschaft steuert, ob die Ereignisüberprüfung für Postback- und Rückrufereignisse aktiviert ist. Wenn diese Option aktiviert ist, werden Argumente für Postback- oder Rückrufereignisse überprüft, um sicherzustellen, dass sie vom Serversteuerelement stammen, das sie ursprünglich gerendert hat.
EnableTheming
Diese Eigenschaft ruft einen Booleschen Wert ab, der angibt, ob ein ASP.NET 2.0-Design auf die Seite angewendet wird oder nicht.
Formular
Diese Eigenschaft gibt das HTML-Formular auf der ASPX-Seite als HtmlForm-Objekt zurück.
Header
Diese Eigenschaft gibt einen Verweis auf ein HtmlHead-Objekt zurück, das den Seitenheader enthält. Sie können das zurückgegebene HtmlHead-Objekt verwenden, um Stylesheets, Metatags usw. abzurufen/festzulegen.
IdSeparator
Diese schreibgeschützte Eigenschaft ruft das Zeichen ab, das zum Trennen von Steuerelementbezeichnern verwendet wird, wenn ASP.NET eine eindeutige ID für Steuerelemente auf einer Seite erstellt. Sie sollte nicht direkt im Code verwendet werden.
IsAsync
Diese Eigenschaft ermöglicht asynchrone Seiten. Asynchrone Seiten werden später in diesem Modul erläutert.
IsCallback
Diese schreibgeschützte Eigenschaft gibt true zurück, wenn die Seite das Ergebnis eines Rückrufs ist. Rückrufe werden später in diesem Modul erläutert.
Iscrosspagepostback
Diese schreibgeschützte Eigenschaft gibt true zurück, wenn die Seite Teil eines seitenübergreifenden Postbacks ist. Seitenübergreifende Postbacks werden später in diesem Modul behandelt.
Items
Gibt einen Verweis auf eine IDictionary-instance zurück, die alle im Seitenkontext gespeicherten Objekte enthält. Sie können diesem IDictionary-Objekt Elemente hinzufügen, die Ihnen während der gesamten Lebensdauer des Kontexts zur Verfügung stehen.
MaintainScrollPositionOnPostBack
Diese Eigenschaft steuert, ob ASP.NET JavaScript ausgibt, das die Bildlaufposition der Seiten im Browser nach einem Postback beibehält. (Details zu dieser Eigenschaft wurden weiter oben in diesem Modul erläutert.)
Master
Diese schreibgeschützte Eigenschaft gibt einen Verweis auf die MasterPage-instance für eine Seite zurück, auf die eine master Seite angewendet wurde.
Masterpagefile
Ruft den master-Seitendateinamen für die Seite ab oder legt diese fest. Diese Eigenschaft kann nur in der PreInit-Methode festgelegt werden.
MaxPageStateFieldLength
Diese Eigenschaft ruft die maximale Länge für den Seitenzustand in Bytes ab oder legt diese fest. Wenn die Eigenschaft auf eine positive Zahl festgelegt ist, wird der Seitenansichtszustand in mehrere ausgeblendete Felder unterteilt, sodass er die angegebene Anzahl von Bytes nicht überschreitet. Wenn die Eigenschaft eine negative Zahl ist, wird der Ansichtszustand nicht in Blöcke unterteilt.
Pageadapter
Gibt einen Verweis auf das PageAdapter-Objekt zurück, das die Seite für den anfordernden Browser ändert.
Previouspage
Gibt in Fällen eines Server.Transfer oder eines seitenübergreifenden Postbacks einen Verweis auf die vorherige Seite zurück.
Skinid
Gibt die ASP.NET 2.0-Skin an, die auf die Seite angewendet werden soll.
Stylesheettheme
Diese Eigenschaft ruft das Stylesheet ab, das auf eine Seite angewendet wird, oder legt es fest.
TemplateControl
Gibt einen Verweis auf das enthaltende Steuerelement für die Seite zurück.
Design
Ruft den Namen des ASP.NET 2.0-Designs ab, das auf die Seite angewendet wird, oder legt diesen fest. Dieser Wert muss vor der PreInit-Methode festgelegt werden.
Titel
Diese Eigenschaft ruft den Titel für die Seite ab, wie er aus der Seitenkopfzeile abgerufen wird, oder legt diesen fest.
Viewstateencryptionmode
Ruft den ViewStateEncryptionMode der Seite ab oder legt diese fest. Weitere Informationen zu dieser Eigenschaft finden Sie weiter oben in diesem Modul.
Neue geschützte Eigenschaften der Page-Klasse
Im Folgenden sind die neuen geschützten Eigenschaften der Page-Klasse in ASP.NET 2.0 aufgeführt.
Adapter
Gibt einen Verweis auf den ControlAdapter zurück, der die Seite auf dem Gerät rendert, das dies angefordert hat.
AsyncMode
Diese Eigenschaft gibt an, ob die Seite asynchron verarbeitet wird. Sie ist für die Verwendung durch die Runtime und nicht direkt im Code vorgesehen.
ClientIDSeparator
Diese Eigenschaft gibt das Zeichen zurück, das beim Erstellen eindeutiger Client-IDs für Steuerelemente als Trennzeichen verwendet wird. Sie ist für die Verwendung durch die Runtime und nicht direkt im Code vorgesehen.
Pagestatepersister
Diese Eigenschaft gibt das PageStatePersister-Objekt für die Seite zurück. Diese Eigenschaft wird in erster Linie von ASP.NET Steuerelemententwicklern verwendet.
UniqueFilePathSuffix
Diese Eigenschaft gibt ein eindeutiges Suffix zurück, das an den Dateipfad zum Zwischenspeichern von Browsern angefügt wird. Der Standardwert ist __ufps= und eine 6-stellige Zahl.
Neue öffentliche Methoden für die Page-Klasse
Die folgenden öffentlichen Methoden sind in der Page-Klasse in ASP.NET 2.0 neu.
Addonprerendercompleteasync
Diese Methode registriert Ereignishandlerdelegaten für die asynchrone Seitenausführung. Asynchrone Seiten werden später in diesem Modul erläutert.
ApplyStyleSheetSkin
Wendet die Eigenschaften in einem Seitenstilblatt auf die Seite an.
Executeregisteredasynctasks
Diese Methode ist eine asynchrone Aufgabe.
GetValidators
Gibt eine Auflistung von Validierungssteuerelementen für die angegebene Validierungsgruppe oder die Standardvalidierungsgruppe zurück, wenn keine angegeben ist.
Registerasynctask
Diese Methode registriert eine neue asynchrone Aufgabe. Asynchrone Seiten werden später in diesem Modul behandelt.
Registerrequirescontrolstate
Diese Methode teilt ASP.NET mit, dass der Zustand der Seitensteuerung beibehalten werden muss.
RegisterRequiresViewStateEncryption
Diese Methode teilt ASP.NET mit, dass der Seitenansichtsstatus eine Verschlüsselung erfordert.
ResolveClientUrl
Gibt eine relative URL zurück, die für Clientanforderungen für Bilder usw. verwendet werden kann.
SetFocus
Diese Methode legt den Fokus auf das Steuerelement fest, das beim anfänglichen Laden der Seite angegeben wird.
UnregisterRequiresControlState
Diese Methode hebt die Registrierung des Steuerelements auf, das an das Steuerelement übergeben wird, da keine Persistenz des Steuerelementzustands mehr erforderlich ist.
Änderungen am Seitenlebenszyklus
Der Seitenlebenszyklus in ASP.NET 2.0 hat sich nicht wesentlich geändert, aber es gibt einige neue Methoden, die Sie kennen sollten. Der ASP.NET 2.0-Seitenlebenszyklus wird unten beschrieben.
PreInit (Neu in ASP.NET 2.0)
Das PreInit-Ereignis ist die früheste Phase im Lebenszyklus, auf die ein Entwickler zugreifen kann. Das Hinzufügen dieses Ereignisses ermöglicht es, ASP.NET 2.0-Designs, master Seiten, Zugriffseigenschaften für ein ASP.NET 2.0-Profil usw. programmgesteuert zu ändern. Wenn Sie sich in einem Postbackzustand befinden, ist es wichtig zu erkennen, dass Viewstate zu diesem Zeitpunkt des Lebenszyklus noch nicht auf Steuerelemente angewendet wurde. Wenn ein Entwickler eine Eigenschaft eines Steuerelements zu diesem Zeitpunkt ändert, wird es wahrscheinlich später im Seitenlebenszyklus überschrieben.
Init
Das Init-Ereignis hat sich gegenüber ASP.NET 1.x nicht geändert. Hier möchten Sie Eigenschaften von Steuerelementen auf Ihrer Seite lesen oder initialisieren. In dieser Phase werden master Seiten, Designs usw. bereits auf die Seite angewendet.
InitComplete (Neu in Version 2.0)
Das InitComplete-Ereignis wird am Ende der Initialisierungsphase der Seiten aufgerufen. An diesem Punkt des Lebenszyklus können Sie auf Steuerelemente auf der Seite zugreifen, deren Status wurde jedoch noch nicht aufgefüllt.
PreLoad (Neu in Version 2.0)
Dieses Ereignis wird aufgerufen, nachdem alle Postbackdaten angewendet wurden und unmittelbar vor Page_Load.
Laden
Das Load-Ereignis hat sich gegenüber ASP.NET 1.x nicht geändert.
LoadComplete (Neu in Version 2.0)
Das LoadComplete-Ereignis ist das letzte Ereignis in der Ladephase der Seiten. In dieser Phase wurden alle Postback- und Viewstate-Daten auf die Seite angewendet.
Prerender
Wenn Sie möchten, dass viewstate für Steuerelemente ordnungsgemäß verwaltet wird, die dynamisch zur Seite hinzugefügt werden, ist das PreRender-Ereignis die letzte Gelegenheit, sie hinzuzufügen.
PreRenderComplete (Neu in Version 2.0)
In der PreRenderComplete-Phase wurden der Seite alle Steuerelemente hinzugefügt, und die Seite kann gerendert werden. Das PreRenderComplete-Ereignis ist das letzte Ereignis, das ausgelöst wird, bevor der Seitenansichtsstatus gespeichert wird.
SaveStateComplete (Neu in Version 2.0)
Das SaveStateComplete-Ereignis wird sofort aufgerufen, nachdem alle Seitenansichts- und Steuerelementstatus gespeichert wurden. Dies ist das letzte Ereignis, bevor die Seite tatsächlich im Browser gerendert wird.
Rendern
Die Render-Methode hat sich seit ASP.NET 1.x nicht geändert. Hier wird der HtmlTextWriter initialisiert und die Seite im Browser gerendert.
Seitenübergreifendes Postback in ASP.NET 2.0
In ASP.NET Version 1.x waren Postbacks erforderlich, um beiträge auf derselben Seite zu veröffentlichen. Seitenübergreifende Postbacks waren nicht zulässig. ASP.NET 2.0 bietet die Möglichkeit, über die IButtonControl-Schnittstelle auf eine andere Seite zurückzugeben. Jedes Steuerelement, das die neue IButtonControl-Schnittstelle implementiert (Button, LinkButton und ImageButton zusätzlich zu benutzerdefinierten Steuerelementen von Drittanbietern), kann diese neue Funktionalität über die Verwendung des PostBackUrl-Attributs nutzen. Der folgende Code zeigt ein Button-Steuerelement, das zu einer zweiten Seite zurückgibt.
<asp:Button ID="SubmitReport" PostBackUrl="~/Default.aspx" runat="server" Text="Submit Report" />
Wenn die Seite zurückgestellt wird, kann auf die Seite, die das Postback initiiert, über die PreviousPage-Eigenschaft auf der zweiten Seite zugegriffen werden. Diese Funktionalität wird über die neue clientseitige funktion WebForm_DoPostBackWithOptions implementiert, die ASP.NET 2.0 auf der Seite gerendert wird, wenn ein Steuerelement auf eine andere Seite zurückgibt. Diese JavaScript-Funktion wird vom neuen WebResource.axd-Handler bereitgestellt, der skripts an den Client ausgibt.
Das folgende Video ist eine exemplarische Vorgehensweise für ein seitenübergreifendes Postback.
Weitere Details zu seitenübergreifenden Postbacks
Viewstate
Möglicherweise haben Sie sich bereits gefragt, was mit dem Viewstate von der ersten Seite in einem seitenübergreifenden Postbackszenario geschieht. Schließlich behält jedes Steuerelement, das IPostBackDataHandler nicht implementiert, seinen Zustand über viewstate bei. Um also Zugriff auf die Eigenschaften dieses Steuerelements auf der zweiten Seite eines seitenübergreifenden Postbacks zu haben, müssen Sie Zugriff auf den Viewstate für die Seite haben. ASP.NET 2.0 übernimmt dieses Szenario mithilfe eines neuen ausgeblendeten Felds auf der zweiten Seite namens __PREVIOUSPAGE. Das Formularfeld __PREVIOUSPAGE enthält den Viewstate für die erste Seite, sodass Sie auf die Eigenschaften aller Steuerelemente auf der zweiten Seite zugreifen können.
Umgehen von FindControl
In der exemplarischen Videoanleitung eines seitenübergreifenden Postbacks habe ich die FindControl-Methode verwendet, um einen Verweis auf das TextBox-Steuerelement auf der ersten Seite abzurufen. Diese Methode funktioniert gut für diesen Zweck, aber FindControl ist teuer und erfordert das Schreiben von zusätzlichem Code. Glücklicherweise bietet ASP.NET 2.0 für diesen Zweck eine Alternative zu FindControl, die in vielen Szenarien funktioniert. Mit der PreviousPageType-Direktive können Sie einen stark typisierten Verweis auf die vorherige Seite verwenden, indem Sie entweder das TypeName- oder das VirtualPath-Attribut verwenden. Mit dem TypeName-Attribut können Sie den Typ der vorherigen Seite angeben, während Sie mit dem VirtualPath-Attribut mithilfe eines virtuellen Pfads auf die vorherige Seite verweisen können. Nachdem Sie die PreviousPageType-Direktive festgelegt haben, müssen Sie die Steuerelemente usw. verfügbar machen. Auf die Sie den Zugriff mithilfe öffentlicher Eigenschaften zulassen möchten.
Lab 1 Seitenübergreifendes Postback
In diesem Lab erstellen Sie eine Anwendung, die die neue seitenübergreifende Postbackfunktion von ASP.NET 2.0 verwendet.
Öffnen Sie Visual Studio 2005, und erstellen Sie eine neue ASP.NET-Website.
Fügen Sie ein neues Webformular mit dem Namen page2.aspx hinzu.
Öffnen Sie default.aspx in der Entwurfsansicht, und fügen Sie ein Button-Steuerelement und ein TextBox-Steuerelement hinzu.
- Weisen Sie dem Button-Steuerelement die ID SubmitButton und dem TextBox-Steuerelement die ID UserName zu.
- Legen Sie die PostBackUrl-Eigenschaft von Button auf page2.aspx fest.
Öffnen Sie page2.aspx in der Quellansicht.
Fügen Sie wie unten gezeigt eine @ PreviousPageType-Direktive hinzu:
Fügen Sie den folgenden Code zum Page_Load des CodeBehinds von page2.aspx hinzu:
Response.Write(PreviousPage.UserName.Text);Erstellen Sie das Projekt, indem Sie im Menü Erstellen auf Erstellen klicken.
Fügen Sie dem CodeBehind für Default.aspx den folgenden Code hinzu:
public TextBox txtUserName { get { return this.UserName; } }Ändern Sie die Page_Load in page2.aspx wie folgt:
Response.Write(PreviousPage.txtUserName.Text);Erstellen Sie das Projekt.
Führen Sie das Projekt aus.
Geben Sie Ihren Namen in das Textfeld ein, und klicken Sie auf die Schaltfläche.
Was ist das Ergebnis?
Asynchrone Seiten in ASP.NET 2.0
Viele Konfliktprobleme in ASP.NET werden durch die Latenz externer Aufrufe (z. B. Webdienst- oder Datenbankaufrufe), Datei-E/A-Latenz usw. verursacht. Wenn eine Anforderung für eine ASP.NET-Anwendung gestellt wird, verwendet ASP.NET einen ihrer Workerthreads, um diese Anforderung zu verarbeiten. Diese Anforderung besitzt diesen Thread, bis die Anforderung abgeschlossen und die Antwort gesendet wurde. ASP.NET 2.0 versucht, Latenzprobleme mit diesen Arten von Problemen zu beheben, indem die Funktion zum asynchronen Ausführen von Seiten hinzugefügt wird. Dies bedeutet, dass ein Workerthread die Anforderung starten und dann eine zusätzliche Ausführung an einen anderen Thread übergeben kann, sodass er schnell zum verfügbaren Threadpool zurückkehrt. Wenn die Datei E/A, datenbank aufruft usw. ist abgeschlossen, wird ein neuer Thread aus dem Threadpool abgerufen, um die Anforderung abzuschließen.
Der erste Schritt bei der asynchronen Ausführung einer Seite besteht darin, das Async-Attribut der Seitendirektive wie folgt festzulegen:
<%@ Page Async="true" %>
Dieses Attribut weist ASP.NET an, den IHttpAsyncHandler für die Seite zu implementieren.
Der nächste Schritt besteht darin, die AddOnPreRenderCompleteAsync-Methode an einem Punkt im Lebenszyklus der Seite vor PreRender aufzurufen. (Diese Methode wird in der Regel in Page_Load aufgerufen.) Die AddOnPreRenderCompleteAsync-Methode verwendet zwei Parameter: ein BeginEventHandler und ein EndEventHandler. Der BeginEventHandler gibt ein IAsyncResult zurück, das dann als Parameter an endEventHandler übergeben wird.
Das folgende Video ist eine exemplarische Vorgehensweise einer asynchronen Seitenanforderung.
Hinweis
Eine asynchrone Seite wird erst im Browser gerendert, wenn der EndEventHandler abgeschlossen ist. Kein Zweifel, aber einige Entwickler werden sich asynchrone Anforderungen als ähnlich wie asynchrone Rückrufe vorstellen. Es ist wichtig zu erkennen, dass dies nicht der Fall ist. Der Vorteil von asynchronen Anforderungen besteht darin, dass der erste Workerthread an den Threadpool zurückgegeben werden kann, um neue Anforderungen zu verarbeiten, wodurch Konflikte aufgrund einer E/A-Bindung usw. reduziert werden.
Skriptrückrufe in ASP.NET 2.0
Webentwickler haben immer nach Möglichkeiten gesucht, das Flimmern im Zusammenhang mit einem Rückruf zu verhindern. In ASP.NET 1.x war SmartNavigation die gebräuchlichste Methode, um Flimmern zu vermeiden, aber SmartNavigation verursachte aufgrund der Komplexität der Implementierung auf dem Client Probleme für einige Entwickler. ASP.NET 2.0 behebt dieses Problem mit Skriptrückrufen. Skriptrückrufe verwenden XMLHttp, um Anforderungen über JavaScript an den Webserver zu senden. Die XMLHttp-Anforderung gibt XML-Daten zurück, die dann über das DOM des Browsers bearbeitet werden können. XMLHttp-Code wird durch den neuen WebResource.axd-Handler für den Benutzer ausgeblendet.
Es gibt mehrere Schritte, die erforderlich sind, um einen Skriptrückruf in ASP.NET 2.0 zu konfigurieren.
Schritt 1: Implementieren der ICallbackEventHandler-Schnittstelle
Damit ASP.NET Ihre Seite als Teil eines Skriptrückrufs erkennen kann, müssen Sie die ICallbackEventHandler-Schnittstelle implementieren. Sie können dies in Ihrer CodeBehind-Datei wie folgt tun:
public partial class _Default : System.Web.UI.Page, ICallbackEventHandler
Sie können dies auch mithilfe der @Implements-Direktive wie folgt tun:
<%@ Implements Interface="System.Web.UI.ICallbackEventHandler" %>
In der Regel verwenden Sie die @ Implements-Direktive, wenn Sie Inlinecode ASP.NET verwenden.
Schritt 2: Aufrufen von GetCallbackEventReference
Wie bereits erwähnt, wird der XMLHttp-Aufruf im WebResource.axd-Handler gekapselt. Wenn Ihre Seite gerendert wird, fügt ASP.NET einen Aufruf von WebForm_DoCallback hinzu, einem Clientskript, das von WebResource.axd bereitgestellt wird. Die funktion WebForm_DoCallback ersetzt die __doPostBack-Funktion durch einen Rückruf. Denken Sie daran, dass __doPostBack das Formular auf der Seite programmgesteuert übermittelt. In einem Rückrufszenario möchten Sie ein Postback verhindern, sodass __doPostBack nicht ausreicht.
Hinweis
__doPostBack wird in einem Clientskriptrückrufszenario weiterhin auf der Seite gerendert. Es wird jedoch nicht für den Rückruf verwendet.
Die Argumente für die WebForm_DoCallback clientseitige Funktion werden über die serverseitige Funktion GetCallbackEventReference bereitgestellt, die normalerweise in Page_Load aufgerufen wird. Ein typischer Aufruf von GetCallbackEventReference könnte wie folgt aussehen:
// Set up the JavaScript callback string cbRef = cm.GetCallbackEventReference(this, "document.getElementById('ddlCompany').value", "ShowCompanyName", "null", true);
Hinweis
In diesem Fall ist cm eine instance von ClientScriptManager. Die ClientScriptManager-Klasse wird später in diesem Modul behandelt.
Es gibt mehrere überladene Versionen von GetCallbackEventReference. In diesem Fall sind die Argumente wie folgt:
this
Ein Verweis auf das Steuerelement, in dem GetCallbackEventReference aufgerufen wird. In diesem Fall handelt es sich um die Seite selbst.
document.getElementById('ddlCompany').value
Ein Zeichenfolgenargument, das vom clientseitigen Code an das serverseitige Ereignis übergeben wird. In diesem Fall übergibt Im den Wert einer Dropdownliste mit dem Namen ddlCompany.
ShowCompanyName
Der Name der clientseitigen Funktion, die den Rückgabewert (als Zeichenfolge) aus dem serverseitigen Rückrufereignis akzeptiert. Diese Funktion wird nur aufgerufen, wenn der serverseitige Rückruf erfolgreich ist. Aus Gründen der Stabilität wird daher im Allgemeinen empfohlen, die überladene Version von GetCallbackEventReference zu verwenden, die ein zusätzliches Zeichenfolgenargument verwendet, das den Namen einer clientseitigen Funktion angibt, die im Fehlerfall ausgeführt werden soll.
null
Eine Zeichenfolge, die eine clientseitige Funktion darstellt, die vor dem Rückruf an den Server initiiert wurde. In diesem Fall gibt es kein solches Skript, sodass das Argument NULL ist.
true
Ein boolescher Wert, der angibt, ob der Rückruf asynchron ausgeführt werden soll.
Der Aufruf von WebForm_DoCallback auf dem Client übergibt diese Argumente. Wenn diese Seite auf dem Client gerendert wird, sieht dieser Code daher wie folgt aus:
WebForm_DoCallback('__Page',document.getElementById('ddlCompany').value, ShowCompanyName,null,null,true)
Beachten Sie, dass die Signatur der Funktion auf dem Client etwas anders ist. Die clientseitige Funktion übergibt fünf Zeichenfolgen und einen Booleschen Wert. Die zusätzliche Zeichenfolge (die im obigen Beispiel NULL ist) enthält die clientseitige Funktion, die alle Fehler des serverseitigen Rückrufs behandelt.
Schritt 3: Einbinden des Client-Side-Steuerelementereignisses
Beachten Sie, dass der Rückgabewert von GetCallbackEventReference oben einer Zeichenfolgenvariablen zugewiesen wurde. Diese Zeichenfolge wird verwendet, um ein clientseitiges Ereignis für das Steuerelement einzuhaken, das den Rückruf initiiert. In diesem Beispiel wird der Rückruf von einer Dropdownliste auf der Seite initiiert, sodass ich das OnChange-Ereignis einbinden möchte.
Um das clientseitige Ereignis einzuhaken, fügen Sie dem clientseitigen Markup einfach wie folgt einen Handler hinzu:
// Hook the JavaScript function to the onchange event of the dropdown ddlCompany.Attributes["onchange"] = String.Format("javascript:{0}", cbRef);
Denken Sie daran, dass cbRef der Rückgabewert aus dem Aufruf von GetCallbackEventReference ist. Sie enthält den aufruf von WebForm_DoCallback, der oben gezeigt wurde.
Schritt 4: Registrieren des Client-Side-Skripts
Erinnern Sie sich daran, dass der Aufruf von GetCallbackEventReference angegeben hat, dass ein clientseitiges Skript mit dem Namen ShowCompanyName ausgeführt wird, wenn der serverseitige Rückruf erfolgreich ist. Dieses Skript muss der Seite mithilfe eines ClientScriptManager-instance hinzugefügt werden. (Die ClientScriptManager-Klasse wird später in diesem Modul erläutert.) Sie tun das wie folgt:
System.Text.StringBuilder clientScript = new System.Text.StringBuilder(""); ClientScriptManager cm = Page.ClientScript; // Create the client script clientScript.Append("function ShowCompanyName(companyName)"); clientScript.Append("{"); clientScript.Append("document.getElementById('CoClicked').innerHTML = \"You chose \" + companyName + \".\";"); clientScript.Append("}"); cm.RegisterClientScriptBlock(this.GetType(), "showCo", clientScript.ToString(), true);
Schritt 5: Aufrufen der Methoden der ICallbackEventHandler-Schnittstelle
Der ICallbackEventHandler enthält zwei Methoden, die Sie in Ihrem Code implementieren müssen. Sie sind RaiseCallbackEvent und GetCallbackEvent.
RaiseCallbackEvent akzeptiert eine Zeichenfolge als Argument und gibt nichts zurück. Das Zeichenfolgenargument wird vom clientseitigen Aufruf an WebForm_DoCallback übergeben. In diesem Fall ist dieser Wert das Value-Attribut der Dropdownliste mit dem Namen ddlCompany. Der serverseitige Code sollte in der RaiseCallbackEvent-Methode platziert werden. Wenn Ihr Rückruf beispielsweise eine WebRequest für eine externe Ressource vornimmt, sollte dieser Code in RaiseCallbackEvent platziert werden.
GetCallbackEvent ist für die Verarbeitung der Rückgabe des Rückrufs an den Client verantwortlich. Es akzeptiert keine Argumente und gibt eine Zeichenfolge zurück. Die zurückgegebene Zeichenfolge wird als Argument an die clientseitige Funktion übergeben, in diesem Fall ShowCompanyName.
Nachdem Sie die oben genannten Schritte ausgeführt haben, können Sie in ASP.NET 2.0 einen Skriptrückruf ausführen.
Skriptrückrufe in ASP.NET werden in jedem Browser unterstützt, der XMLHttp-Aufrufe unterstützt. Dazu gehören alle modernen Browser, die heute verwendet werden. Internet Explorer verwendet das XMLHttp ActiveX-Objekt, während andere moderne Browser (einschließlich des bevorstehenden IE 7) ein systeminternes XMLHttp-Objekt verwenden. Um programmgesteuert zu ermitteln, ob ein Browser Rückrufe unterstützt, können Sie die Request.Browser.SupportCallback-Eigenschaft verwenden. Diese Eigenschaft gibt true zurück, wenn der anfordernde Client Skriptrückrufe unterstützt.
Arbeiten mit Clientskript in ASP.NET 2.0
Clientskripts in ASP.NET 2.0 werden mithilfe der ClientScriptManager-Klasse verwaltet. Die ClientScriptManager-Klasse verfolgt Clientskripts mit einem Typ und einem Namen nach. Dadurch wird verhindert, dass dasselbe Skript mehr als einmal programmgesteuert auf einer Seite eingefügt wird.
Hinweis
Nachdem ein Skript erfolgreich auf einer Seite registriert wurde, führt jeder nachfolgende Versuch, dasselbe Skript zu registrieren, einfach dazu, dass das Skript nicht ein zweites Mal registriert wird. Es werden keine doppelten Skripts hinzugefügt, und es tritt keine Ausnahme auf. Um unnötige Berechnungen zu vermeiden, gibt es Methoden, mit denen Sie ermitteln können, ob ein Skript bereits registriert ist, sodass Sie nicht versuchen, es mehrmals zu registrieren.
Die Methoden des ClientScriptManager sollten allen aktuellen ASP.NET Entwicklern vertraut sein:
Registerclientscriptblock
Diese Methode fügt oben auf der gerenderten Seite ein Skript hinzu. Dies ist nützlich, um Funktionen hinzuzufügen, die explizit auf dem Client aufgerufen werden.
Es gibt zwei überladene Versionen dieser Methode. Drei von vier Argumenten sind üblich. Sie lauten wie folgt:
type (string)
Das Type-Argument identifiziert einen Typ für das Skript. Es ist im Allgemeinen eine gute Idee, den Typ der Seite zu verwenden (dies. GetType()) für den Typ.
key (string)
Das Schlüsselargument ist ein benutzerdefinierter Schlüssel für das Skript. Dies sollte für jedes Skript eindeutig sein. Wenn Sie versuchen, ein Skript mit demselben Schlüssel und Typ eines bereits hinzugefügten Skripts hinzuzufügen, wird es nicht hinzugefügt.
script (string)
Das Skriptargument ist eine Zeichenfolge, die das tatsächlich hinzuzufügende Skript enthält. Es wird empfohlen, dass Sie einen StringBuilder verwenden, um das Skript zu erstellen, und dann die ToString()-Methode für den StringBuilder verwenden, um das Skriptargument zuzuweisen.
Wenn Sie den überladenen RegisterClientScriptBlock verwenden, der nur drei Argumente akzeptiert, müssen Sie Skriptelemente (<script> und </script>) in Ihr Skript einschließen.
Sie können die Überladung von RegisterClientScriptBlock verwenden, die ein viertes Argument akzeptiert. Das vierte Argument ist ein boolescher Wert, der angibt, ob ASP.NET Skriptelemente für Sie hinzufügen soll. Wenn dieses Argument true ist, sollte Ihr Skript die Skriptelemente nicht explizit enthalten.
Verwenden Sie die IsClientScriptBlockRegistered-Methode, um zu ermitteln, ob bereits ein Skript registriert wurde. Dadurch können Sie vermeiden, dass versucht wird, ein bereits registriertes Skript erneut zu registrieren.
RegisterClientScriptInclude (Neu in Version 2.0)
Das RegisterClientScriptInclude-Tag erstellt einen Skriptblock, der mit einer externen Skriptdatei verknüpft ist. Es verfügt über zwei Überladungen. Man akzeptiert einen Schlüssel und eine URL. Die zweite fügt ein drittes Argument hinzu, das den Typ angibt.
Der folgende Code generiert beispielsweise einen Skriptblock, der auf jsfunctions.js im Stammverzeichnis des Skriptordners der Anwendung verweist:
ClientScriptManager cm = Page.ClientScript; if(!cm.IsClientScriptIncludeRegistered("jsfunc")) { cm.RegisterClientScriptInclude(this.GetType(), "jsfunc", "/scripts/jsfunctions.js"); }
Dieser Code erzeugt den folgenden Code auf der gerenderten Seite:
<script src="/scripts/jsfunctions.js" type="text/javascript"></script>
Hinweis
Der Skriptblock wird unten auf der Seite gerendert.
Verwenden Sie die IsClientScriptIncludeRegistered-Methode, um zu ermitteln, ob bereits ein Skript registriert wurde. Dadurch können Sie vermeiden, dass versucht wird, ein Skript erneut zu registrieren.
Registerstartupscript
Die RegisterStartupScript-Methode verwendet die gleichen Argumente wie die RegisterClientScriptBlock-Methode. Ein bei RegisterStartupScript registriertes Skript wird ausgeführt, nachdem die Seite geladen wurde, aber vor dem clientseitigen OnLoad-Ereignis. In 1.X wurden mit RegisterStartupScript registrierte Skripts direkt vor dem schließenden <Tag /form> platziert, während skripts, die mit RegisterClientScriptBlock registriert wurden, unmittelbar nach dem öffnenden <Formulartag> platziert wurden. In ASP.NET 2.0 werden beide unmittelbar vor dem schließenden <Tag /form> platziert.
Hinweis
Wenn Sie eine Funktion bei RegisterStartupScript registrieren, wird diese Funktion erst ausgeführt, wenn Sie sie explizit im clientseitigen Code aufrufen.
Verwenden Sie die IsStartupScriptRegistered-Methode, um zu ermitteln, ob ein Skript bereits registriert wurde, und vermeiden Sie den Versuch, ein Skript erneut zu registrieren.
Andere ClientScriptManager-Methoden
Hier sind einige der anderen nützlichen Methoden der ClientScriptManager-Klasse aufgeführt.
| Getcallbackeventreference | Weitere Informationen finden Sie unter Skriptrückrufe weiter oben in diesem Modul. |
|---|---|
| GetPostBackClientHyperlink | Ruft einen JavaScript-Verweis (javascript:<call>) ab, der verwendet werden kann, um die Post von einem clientseitigen Ereignis zurück zu senden. |
| Getpostbackeventreference | Ruft eine Zeichenfolge ab, mit der ein Postback vom Client initiiert werden kann. |
| GetWebResourceUrl | Gibt eine URL für eine Ressource zurück, die in eine Assembly eingebettet ist. Muss in Verbindung mit RegisterClientScriptResource verwendet werden. |
| Registerclientscriptresource | Registriert eine Webressource bei der Seite. Dies sind Ressourcen, die in eine Assembly eingebettet sind und vom neuen WebResource.axd-Handler verarbeitet werden. |
| Registerhiddenfield | Registriert ein ausgeblendetes Formularfeld bei der Seite. |
| Registeronsubmitstatement | Registriert clientseitigen Code, der ausgeführt wird, wenn das HTML-Formular gesendet wird. |
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für