Serversteuerelemente
von Microsoft
ASP.NET 2.0 verbessert die Serversteuerelemente in vielerlei Hinsicht. In diesem Modul werden einige der Architektonischen Änderungen im Umgang mit Serversteuerelementen ASP.NET 2.0 und Visual Studio 2005 behandelt.
ASP.NET 2.0 verbessert die Serversteuerelemente in vielerlei Hinsicht. In diesem Modul werden einige der Architektonischen Änderungen im Umgang mit Serversteuerelementen ASP.NET 2.0 und Visual Studio 2005 behandelt.
Anzeigen des Zustands
Die primäre Änderung des Ansichtszustands in ASP.NET 2.0 ist eine dramatische Verkleinerung der Größe. Stellen Sie sich eine Seite vor, auf der nur ein Calendar-Steuerelement enthalten ist. Hier ist der Ansichtszustand in ASP.NET 1.1.
dDwtMTg1NDkwMjc0Nzt0PDtsPGk8MT47PjtsPHQ8O2w8aTwxPjs
+O2w8dDxAMDxwPHA8bDxTRDs+O2w8bDxTeXN0ZW0uRGF0ZVRpbWUsIG1
zY29ybGliLCBWZXJzaW9uPTEuMC41MDAwLjAsIEN1bHR1cmU9bmV1dHJ
hbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OTwyMDA1LTE
xLTA4Pjs+Oz4+Oz47Ozs7Ozs7Ozs7Pjs7Pjs+Pjs+Pjs+lkX2YWqfACtP
/VWr8G03pob/+tU=
Hier ist der Ansichtszustand auf einer identischen Seite in ASP.NET 2.0.
/wEPDwULLTEzNjg5MjAxMzgPZBYCAgMPZBYCAgEPPCsAC
gEADxYCHgJTRBYBBgDAEX8OsscIZGRkllfArINjlhvzQX7Xfign2q6HK5E=
Dies ist eine ziemlich bedeutende Änderung, und wenn man bedenkt, dass der Ansichtszustand über den Draht hin- und hergetragen wird, kann diese Änderung Entwicklern eine erhebliche Leistungssteigerung ermöglichen. Die Verringerung der Größe des Ansichtszustands ist größtenteils auf die Art und Weise zurückzuführen, wie wir ihn intern behandeln. Denken Sie daran, dass der Ansichtszustand eine Base64-codierte Zeichenfolge ist. Um die Änderung des Ansichtszustands in ASP.NET 2.0 besser zu verstehen, werfen wir einen Blick auf die decodierten Werte aus den obigen Beispielen.
Hier ist der Ansichtszustand 1.1 decodiert:
t<-1854902747;t<;l<i<1>;>;l<t<;l<
i<1>;>;l<t<@0<p<p<l<SD;>;l<l<
System.DateTime, mscorlib, Version=1.0.5000.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089<2005-11-08>;>;>>;
>;;;;;;;;;;>;;>;>>;>>;>Eaj
Dies mag ein wenig wie Kauderwelsch aussehen, aber es gibt hier ein Muster. In ASP.NET 1.x haben wir einzelne Zeichen verwendet, um Datentypen zu identifizieren und Werte mit Trennzeichen anhand der <> Zeichen zu identifizieren. Das "t" im obigen Ansichtszustandsbeispiel stellt ein Triplet dar. Das Triplet enthält ein ArrayLists-Paar (das "l" stellt eine ArrayList dar.) Eines dieser ArrayLists enthält ein Int32 ("i") mit dem Wert 1 und das andere enthält ein weiteres Triplet. Das Triplet enthält ein Paar von ArrayLists usw. Wichtig ist, dass wir Triplets verwenden, die Paare enthalten, wir identifizieren die Datentypen über einen Buchstaben und verwenden die < Zeichen und > als Trennzeichen.
In ASP.NET 2.0 sieht der decodierte Ansichtszustand etwas anders aus.
-1368920138 d
d
SD
dddWc A ('ڮ
Sie sollten eine große Änderung in der Darstellung des decodierten Ansichtszustands feststellen. Diese Änderung hat mehrere architektonische Grundlagen. Der Ansichtszustand in ASP.NET 1.x verwendet losFormatter zum Serialisieren von Daten. In Version 2.0 verwenden wir die neue ObjectStateFormatter-Klasse. Diese Klasse wurde speziell entwickelt, um die Serialisierung und Deserialisierung des Ansichtszustands und des Steuerungszustands zu unterstützen. (Der Steuerungszustand wird im nächsten Abschnitt behandelt.) Es gibt viele Vorteile, wenn die Methode geändert wird, mit der Serialisierung und Deserialisierung erfolgen. Einer der dramatischsten ist die Tatsache, dass im Gegensatz zum LosFormatter, der einen TextWriter verwendet, objectStateFormatter einen BinaryWriter verwendet. Dies ermöglicht ASP.NET 2.0, den Ansichtszustand eine Reihe von Bytes anstelle von Zeichenfolgen zu speichern. Nehmen wir beispielsweise eine ganze Zahl. In ASP.NET 1.1 erforderte eine ganze Zahl 4 Byte Ansichtszustand. In ASP.NET 2.0 erfordert dieselbe Ganze Zahl nur 1 Byte. Es wurden weitere Verbesserungen vorgenommen, um die Menge des gespeicherten Ansichtszustands zu verringern. DateTime-Werte werden beispielsweise jetzt mit einem TickCount anstelle einer Zeichenfolge gespeichert.
Als ob das alles nicht genug wäre, wurde besonderes Augenmerk darauf gelegt, dass einer der größten Consumer des Ansichtszustands in 1.x das DataGrid und ähnliche Steuerelemente war. Ein großer Nachteil von Steuerelementen wie dem DataGrid für den Ansichtszustand besteht darin, dass es häufig große Mengen wiederholter Informationen enthält. In ASP.NET 1.x wurden diese wiederholten Informationen einfach immer wieder gespeichert, was zu einem aufgeblähten Ansichtszustand führte. In ASP.NET 2.0 verwenden wir die neue IndexedString-Klasse, um solche Daten zu speichern. Wenn eine Zeichenfolge wiederholt wird, speichern wir einfach das Token für den IndexedString und den Index in einer ausgeführten Tabelle von IndexedString-Objekten.
Steuerungsstatus
Eine der wichtigsten Fehler, die Entwickler mit dem Ansichtszustand hatten, war die Größe, die sie der HTTP-Nutzlast hinzugefügt haben. Wie bereits erwähnt, ist einer der größten Consumer des Ansichtszustands das DataGrid-Steuerelement. Um die riesigen Mengen des Ansichtszustands zu vermeiden, die von einem DataGrid generiert werden, haben viele Entwickler den Ansichtszustand für dieses Steuerelement einfach deaktiviert. Leider war diese Lösung nicht immer eine gute. Der Ansichtszustand in ASP.NET 1.x enthält nicht nur Daten, die für die korrekte Funktionalität des Steuerelements erforderlich sind. Außerdem enthält sie Informationen zum Zustand der Benutzeroberfläche des Steuerelements. Wenn Sie also die Paginierung für ein DataGrid zulassen möchten, müssen Sie den Ansichtszustand auch dann aktivieren, wenn Sie nicht alle Ui-Informationen benötigen, die der Ansichtszustand enthält. Es handelt sich um ein Alles-oder-Nichts-Szenario.
In ASP.NET 2.0 löst der Steuerungszustand dieses Problem gut durch die Einführung des Steuerzustands. Der Steuerelementzustand enthält die Daten, die für die ordnungsgemäße Funktionalität eines Steuerelements absolut erforderlich sind. Im Gegensatz zum Ansichtszustand kann der Steuerelementzustand nicht deaktiviert werden. Daher ist es wichtig, dass die Daten, die im Kontrollzustand gespeichert werden, sorgfältig kontrolliert werden.
Hinweis
Der Steuerelementzustand wird zusammen mit dem Ansichtszustand im feld __VIEWSTATE ausgeblendeten Formulars beibehalten.
Dieses Video ist eine exemplarische Vorgehensweise für den Ansichts- und Steuerungszustand.
Damit ein Serversteuerelement den Zustand des Steuerelements lesen und schreiben kann, müssen Sie drei Schritte ausführen.
Schritt 1: Aufrufen der RegisterRequiresControlState-Methode
Die RegisterRequiresControlState-Methode informiert ASP.NET, dass ein Steuerelement den Steuerungszustand beibehalten muss. Sie verwendet ein Argument vom Typ Control, das das Steuerelement ist, das registriert wird.
Es ist wichtig zu beachten, dass die Registrierung von Anforderung zu Anforderung nicht beibehalten wird. Daher muss diese Methode bei jeder Anforderung aufgerufen werden, wenn ein Steuerelement den Steuerungszustand beibehalten soll. Es wird empfohlen, dass die -Methode in OnInit aufgerufen wird.
protected override void OnInit(EventArgs e) { Page.RegisterRequiresControlState(this); base.OnInit(e); }
Schritt 2: Überschreiben von SaveControlState
Die SaveControlState-Methode speichert Änderungen des Steuerelementzustands für ein Steuerelement seit dem letzten Postback. Es gibt ein Objekt zurück, das den Zustand des Steuerelements darstellt.
Schritt 3: Überschreiben von LoadControlState
Die LoadControlState-Methode lädt den gespeicherten Zustand in ein Steuerelement. Die -Methode verwendet ein Argument vom Typ Object, das den gespeicherten Zustand für das Steuerelement enthält.
Vollständige XHTML-Kompatibilität
Jeder Webentwickler kennt die Bedeutung von Standards in Webanwendungen. Um eine standardbasierte Entwicklungsumgebung aufrechtzuerhalten, ist ASP.NET 2.0 vollständig XHTML-kompatibel. Daher werden alle Tags nach XHTML-Standards in Browsern gerendert, die HTML 4.0 oder höher unterstützen.
Die DOCTYPE-Definition in ASP.NET 1.1 lautete wie folgt:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN
In ASP.NET 2.0 lautet die DOCTYPE-Standarddefinition wie folgt:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Wenn Sie dies auswählen, können Sie die XHTML-Standardkonformität über den Knoten xhtmlConformance in der Konfigurationsdatei ändern. Beispielsweise ändert der folgende Knoten in der datei web.config XHTML-Konformität in XHTML 1.0 Strict:
<xhtmlConformance mode="Strict" />
Wenn Sie dies auswählen, können Sie auch ASP.NET so konfigurieren, dass die in ASP.NET 1.x verwendete Legacykonfiguration wie folgt verwendet wird:
<xhtmlConformance mode="Legacy" />
Adaptives Rendering mithilfe von Adaptern
In ASP.NET 1.x enthielt die Konfigurationsdatei einen <browserCaps-Abschnitt> , in dem ein HttpBrowserCapabilities-Objekt aufgefüllt wurde. Dieses Objekt ermöglichte es einem Entwickler, zu bestimmen, welches Gerät eine bestimmte Anforderung vornimmt, und code entsprechend zu rendern. In ASP.NET 2.0 wurde das Modell verbessert und verwendet jetzt die neue ControlAdapter-Klasse. Die ControlAdapter-Klasse überschreibt Ereignisse im Lebenszyklus des Steuerelements und steuert das Rendern von Steuerelementen basierend auf den Funktionen des Benutzer-Agents. Die Funktionen eines bestimmten Benutzer-Agents werden durch eine Browserdefinitionsdatei (eine Datei mit der Browserdateierweiterung) definiert, die im Ordner c:\windows\microsoft.net\framework\v2.0.****\CONFIG\Browsers gespeichert ist.
Hinweis
Die ControlAdapter-Klasse ist eine abstrakte Klasse.
Ähnlich wie im <BrowserCaps-Abschnitt in Version 1.x verwendet die Browserdefinitionsdatei> einen regulären Ausdruck, um die Benutzer-Agent-Zeichenfolge zu analysieren, um den anfordernden Browser zu identifizieren. Sie definiert bestimmte Funktionen für diesen Benutzer-Agent. Der ControlAdapter rendert das Steuerelement über die Render-Methode. Wenn Sie daher die Render-Methode überschreiben, sollten Sie Render nicht für die Basisklasse aufrufen. Dies kann dazu führen, dass das Rendering zweimal erfolgt, einmal für den Adapter und einmal für das Steuerelement selbst.
Entwickeln eines benutzerdefinierten Adapters
Sie können Einen eigenen benutzerdefinierten Adapter entwickeln, indem Sie von ControlAdapter erben. Darüber hinaus können Sie von der abstrakten Klasse PageAdapter erben, wenn für eine Seite ein Adapter benötigt wird. Die Zuordnung von Steuerelementen zu Ihrem benutzerdefinierten Adapter erfolgt über das <controlAdapters-Element in der Browserdefinitionsdatei> . Der folgende XML-Code aus einer Browserdefinitionsdatei ordnet beispielsweise das Menu-Steuerelement der MenuAdapter-Klasse zu:
<controlAdapters> <adapter controlType="System.Web.UI.WebControls.Menu" adapterType="System.Web.UI.WebControls.Adapters.MenuAdapter" /> </controlAdapters>
Mit diesem Modell wird es für einen Steuerelemententwickler recht einfach, ein bestimmtes Gerät oder einen bestimmten Browser als Ziel zu verwenden. Es ist auch ganz einfach für einen Entwickler, die vollständige Kontrolle darüber zu haben, wie Seiten auf jedem Gerät gerendert werden.
Per-Device Rendering
Serversteuerelementeigenschaften in ASP.NET 2.0 können gerätespezifisch mit einem browserspezifischen Präfix angegeben werden. Der folgende Code ändert beispielsweise den Text einer Bezeichnung, je nachdem, welches Gerät zum Durchsuchen der Seite verwendet wird.
<asp:Label ID="lblBrowser" runat="server" Text="You are browsing from an unknown device." ie:Text="You are browsing from Internet Explorer." mozilla:Text="You are browsing from Firefox."> </asp:Label>
Wenn die Seite, die diese Bezeichnung enthält, über das Internet Explorer durchsucht wird, wird auf der Beschriftung der Text angezeigt, der besagt: "Sie surfen aus dem Internet Explorer". Wenn die Seite von Firefox aus durchsucht wird, wird auf der Bezeichnung der Text "Sie surfen von Firefox aus" angezeigt. Wenn die Seite von einem anderen Gerät aus durchsucht wird, wird "Sie surfen von einem unbekannten Gerät aus". Jede Eigenschaft kann mit dieser speziellen Syntax angegeben werden.
Festlegen des Fokus
ASP.NET 1.x-Entwickler häufig gefragt, wie sie den anfänglichen Fokus auf ein bestimmtes Steuerelement festlegen. Auf einer Anmeldeseite ist es beispielsweise nützlich, dass das Textfeld Benutzer-ID den Fokus erhält, wenn die Seite zum ersten Mal geladen wird. In ASP.NET 1.x erforderte dies das Schreiben eines clientseitigen Skripts. Obwohl ein solches Skript eine triviale Aufgabe ist, ist es in ASP.NET 2.0 dank der SetFocus-Methode nicht mehr erforderlich. Die SetFocus-Methode verwendet ein Argument, das das Steuerelement angibt, das den Fokus erhalten soll. Bei diesem Argument kann es sich entweder um die Client-ID des Steuerelements als Zeichenfolge oder um den Namen des Serversteuerelements als Control-Objekt handeln. Wenn Sie beispielsweise beim ersten Laden der Seite den anfänglichen Fokus auf ein TextBox-Steuerelement namens txtUserID festlegen möchten, fügen Sie Page_Load den folgenden Code hinzu:
if (!IsPostBack) {
SetFocus(txtUserID);
}
--Oder
if (!IsPostBack) {
SetFocus(txtUserID.ClientID);
}
ASP.NET 2.0 verwendet den Webresource.axd-Handler (weiter oben erläutert), um eine clientseitige Funktion zu rendern, die den Fokus festlegt. Der Name der clientseitigen Funktion ist wie hier gezeigt WebForm_AutoFocus:
<script type="text/javascript"> <!-- WebForm_AutoFocus('txtUserID'); // --> </script>
Alternativ können Sie die Focus-Methode für ein Steuerelement verwenden, um den anfänglichen Fokus auf dieses Steuerelement festzulegen. Die Focus-Methode stammt von der Control-Klasse und ist für alle ASP.NET 2.0-Steuerelemente verfügbar. Es ist auch möglich, den Fokus auf ein bestimmtes Steuerelement festzulegen, wenn ein Validierungsfehler auftritt. Dies wird in einem späteren Modul behandelt.
Neue Serversteuerelemente in ASP.NET 2.0
Im Folgenden sind neue Serversteuerelemente in ASP.NET 2.0 aufgeführt. Einige davon werden in späteren Modulen ausführlicher erläutert.
ImageMap-Steuerelement
Mit dem ImageMap-Steuerelement können Sie Einem Bild Hotspots hinzufügen, die einen Beitrag zurück initiieren oder zu einer URL navigieren können. Es gibt drei Arten von Hotspots: CircleHotSpot, RectangleHotSpot und PolygonHotSpot. Hotspots werden über einen Sammlungs-Editor in Visual Studio oder programmgesteuert im Code hinzugefügt. Es ist keine Benutzeroberfläche zum Zeichnen von Hotspots auf einem Bild verfügbar. Koordinaten und Größe oder Radius des Hotspots müssen deklarativ angegeben werden. Es gibt auch keine visuelle Darstellung eines Hotspots im Designer. Wenn ein Hotspot für die Navigation zu einer URL konfiguriert ist, wird die URL über die NavigateUrl-Eigenschaft des Hotspots angegeben. Im Fall eines Postback-Hotspots können Sie mit der PostBackValue-Eigenschaft eine Zeichenfolge im Postback übergeben, die im serverseitigen Code abgerufen werden kann.
Abbildung 1: HotSpot-Sammlungs-Editor in Visual Studio
BulletedList-Steuerelement
Das BulletedList-Steuerelement ist eine Aufzählung, die problemlos datengebunden sein kann. Die Liste kann über die BulletStyle-Eigenschaft sortiert (nummeriert) oder ungeordnet werden. Jedes Element in der Liste wird durch ein ListItem-Objekt dargestellt.
Abbildung 2: BulletedList-Steuerelement in Visual Studio
HiddenField-Steuerelement
Das HiddenField-Steuerelement fügt Ihrer Seite ein ausgeblendetes Formularfeld hinzu, dessen Wert im serverseitigen Code verfügbar ist. Es wird davon ausgegangen, dass der Wert eines ausgeblendeten Formularfelds zwischen den Postbacks unverändert bleibt. Es ist jedoch möglich, dass ein böswilliger Benutzer den Wert vor dem Postback ändern kann. In diesem Fall löst das HiddenField-Steuerelement das ValueChanged-Ereignis aus. Wenn Sie über vertrauliche Informationen im HiddenField-Steuerelement verfügen und sicherstellen möchten, dass es unverändert bleibt, sollten Sie das ValueChanged-Ereignis in Ihrem Code behandeln.
FileUpload-Steuerelement
Das FileUpload-Steuerelement in ASP.NET 2.0 ermöglicht das Hochladen von Dateien auf einen Webserver über eine ASP.NET Seite. Dieses Steuerelement ähnelt mit wenigen Ausnahmen der ASP.NET 1.x HtmlInputFile-Klasse. In ASP.NET 1.x wurde empfohlen, die PostedFile-Eigenschaft auf NULL zu überprüfen, um festzustellen, ob Sie eine gute Datei hatten. Das FileUpload-Steuerelement in ASP.NET 2.0 fügt eine neue HasFile-Eigenschaft hinzu, die Sie für denselben Zweck verwenden können, und es ist etwas effizienter.
Die PostedFile-Eigenschaft ist weiterhin für den Zugriff auf ein HttpPostedFile-Objekt verfügbar, aber ein Teil der Funktionen von HttpPostedFile ist jetzt systemintern mit dem FileUpload-Steuerelement verfügbar. Um beispielsweise eine hochgeladene Datei in ASP.NET 1.x zu speichern, rufen Sie die SaveAs-Methode für das HttpPostedFile-Objekt auf. Mit dem FileUpload-Steuerelement in ASP.NET 2.0 würden Sie die SaveAs-Methode für das FileUpload-Steuerelement selbst aufrufen.
Eine weitere wichtige Änderung im Verhalten von 2.0 (und wahrscheinlich die wichtigste Änderung) ist, dass es nicht mehr erforderlich ist, eine gesamte hochgeladene Datei vor dem Speichern in den Arbeitsspeicher zu laden. In 1.x wird jede datei, die hochgeladen wurde, vollständig im Arbeitsspeicher gespeichert, bevor sie auf den Datenträger geschrieben wird. Diese Architektur verhindert das Hochladen großer Dateien.
In ASP.NET 2.0 können Sie mit dem Attribut requestLengthDiskThreshold des httpRuntime-Elements konfigurieren, wie viele Kilobytes in einem Puffer im Arbeitsspeicher gespeichert werden, bevor sie auf den Datenträger geschrieben werden.
WICHTIG: Die MSDN-Dokumentation (und die Dokumentation an anderer Stelle) gibt an, dass dieser Wert in Bytes (nicht in Kilobytes) und dass der Standardwert 256 ist. Der Wert wird tatsächlich in Kilobytes angegeben, und der Standardwert ist 80. Durch den Standardwert 80K stellen wir sicher, dass der Puffer nicht auf dem Heap für große Objekte landet.
Assistentensteuerelement
Es ist ziemlich üblich, ASP.NET Entwickler mit dem Versuch zu kämpfen, Informationen in einer Reihe von "Seiten" mithilfe von Panels oder durch übertragen von Seite zu Seite zu sammeln. In den meisten Fällen ist das Unterfangen frustrierend und zeitaufwändig. Das neue Wizard-Steuerelement löst die Probleme, indem lineare und nicht lineare Schritte in einer Assistentenoberfläche zugelassen werden, mit der Benutzer vertraut sind. Das Wizard-Steuerelement stellt Eingabeformulare in einer Reihe von Schritten dar. Jeder Schritt hat einen bestimmten Typ, der von der StepType-Eigenschaft des Steuerelements angegeben wird. Die verfügbaren Schritttypen sind wie folgt:
| Schritttyp | Erklärung |
|---|---|
| Automatisch | Der Assistent bestimmt automatisch den Typ des Schritts basierend auf seiner Position in der Schritthierarchie. |
| Start | Der erste Schritt, der häufig verwendet wird, um eine einführungsweisen Erklärung zu präsentieren. |
| Schritt | Ein normaler Schritt. |
| Finish | Der letzte Schritt, der normalerweise verwendet wird, um eine Schaltfläche anzuzeigen, um den Assistenten abzuschließen. |
| Abgeschlossen | Zeigt eine Nachricht an, die Erfolg oder Fehler kommuniziert. |
Hinweis
Das Wizard-Steuerelement verfolgt seinen Zustand mithilfe ASP.NET-Steuerelementstatus nach. Daher kann die EnableViewState-Eigenschaft ohne Nachteil auf false festgelegt werden.
Dieses Video ist eine exemplarische Vorgehensweise des Assistenten-Steuerelements.
Steuerung lokalisieren
Das Localize-Steuerelement ähnelt einem Literal-Steuerelement. Das Localize-Steuerelement verfügt jedoch über eine Mode-Eigenschaft , die steuert, wie Markup, das hinzugefügt wird, gerendert wird. Die Mode-Eigenschaft unterstützt die folgenden Werte:
| Mode | Erklärung |
|---|---|
| Transformieren | Markup wird entsprechend dem Protokoll des Browsers transformiert, der die Anforderung stellt. |
| Passthrough | Markup wird unverändert gerendert. |
| Codieren | Markup, das dem Steuerelement hinzugefügt wird, wird mit HtmlEncode codiert. |
MultiView- und Ansichtssteuerelemente
Das MultiView-Steuerelement fungiert als Container für View-Steuerelemente, und das View-Steuerelement fungiert als Container (ähnlich wie ein Panel-Steuerelement) für andere Steuerelemente. Jede Ansicht in einem MultiView-Steuerelement wird durch ein einzelnes View-Steuerelement dargestellt. Das erste Ansicht-Steuerelement in MultiView ist Ansicht 0, das zweite ist Ansicht 1 usw. Sie können die Ansichten wechseln, indem Sie den ActiveViewIndex des MultiView-Steuerelements angeben.
Ersetzungssteuerung
Das Ersetzungssteuerelement wird in Verbindung mit ASP.NET Zwischenspeicherung verwendet. In Fällen, in denen Sie die Vorteile der Zwischenspeicherung nutzen möchten, aber Über Teile einer Seite verfügen, die bei jeder Anforderung aktualisiert werden müssen (d. h. Teile einer Seite, die von der Zwischenspeicherung ausgenommen sind), bietet die Ersetzungskomponente eine hervorragende Lösung. Das Steuerelement rendert keine Ausgabe selbst. Stattdessen wird sie an eine Methode im serverseitigen Code gebunden. Wenn die Seite angefordert wird, wird die -Methode aufgerufen, und das zurückgegebene Markup wird anstelle des Ersetzungssteuerelements gerendert.
Die Methode, an die das Substitutionssteuerelement gebunden ist, wird über die MethodName-Eigenschaft angegeben. Diese Methode muss die folgenden Kriterien erfüllen:
- Es muss sich um eine statische (in VB freigegebene) Methode sein.
- Sie akzeptiert einen Parameter vom Typ HttpContext.
- Sie gibt eine Zeichenfolge zurück, die das Markup darstellt, das das Steuerelement auf der Seite ersetzen soll.
Das Ersetzungssteuerelement kann kein anderes Steuerelement auf der Seite ändern, hat aber über seinen Parameter Zugriff auf den aktuellen HttpContext.
GridView-Steuerelement
Das GridView-Steuerelement ist der Ersatz für das DataGrid-Steuerelement. Dieses Steuerelement wird in einem späteren Modul ausführlicher behandelt.
DetailsView-Steuerelement
Mit dem DetailsView-Steuerelement können Sie einen einzelnen Datensatz aus einer Datenquelle anzeigen und ihn bearbeiten oder löschen. Dies wird in einem späteren Modul ausführlicher behandelt.
FormView-Steuerelement
Das FormView-Steuerelement wird verwendet, um einen einzelnen Datensatz aus einer Datenquelle in einer konfigurierbaren Schnittstelle anzuzeigen. Dies wird in einem späteren Modul ausführlicher behandelt.
AccessDataSource-Steuerelement
Das AccessDataSource-Steuerelement wird zum Binden von Daten an eine Access-Datenbank verwendet. Dies wird in einem späteren Modul ausführlicher behandelt.
ObjectDataSource-Steuerelement
Das ObjectDataSource-Steuerelement wird verwendet, um eine Architektur mit drei Ebenen zu unterstützen, sodass Steuerelemente an ein Geschäftsobjekt der mittleren Ebene und nicht an ein Modell mit zwei Ebenen gebunden werden können, bei dem Steuerelemente direkt an die Datenquelle gebunden werden. Dies wird in einem späteren Modul ausführlicher erläutert.
XmlDataSource-Steuerelement
Das XmlDataSource-Steuerelement wird verwendet, um Daten an eine XML-Datenquelle zu binden. Dies wird in einem späteren Modul ausführlicher behandelt.
SiteMapDataSource-Steuerelement
Das SiteMapDataSource-Steuerelement stellt die Datenbindung für Websitenavigationssteuerelemente basierend auf einer Websiteübersicht bereit. Dies wird in einem späteren Modul ausführlicher erläutert.
SiteMapPath-Steuerelement
Das SiteMapPath-Steuerelement zeigt eine Reihe von Navigationslinks an, die häufig als Breadcrumbs bezeichnet werden. Dies wird in einem späteren Modul ausführlicher behandelt.
Menu-Steuerelement
Das Menü-Steuerelement zeigt dynamische Menüs mithilfe von DHTML an. Dies wird in einem späteren Modul ausführlicher behandelt.
TreeView-Steuerelement
Das TreeView-Steuerelement wird verwendet, um eine hierarchische Strukturansicht von Daten anzuzeigen. Dies wird in einem späteren Modul ausführlicher behandelt.
Anmeldesteuerelement
Das Anmeldesteuerelement bietet einen Mechanismus für die Anmeldung bei einer Website. Dies wird in einem späteren Modul ausführlicher behandelt.
LoginView-Steuerelement
Das LoginView-Steuerelement ermöglicht die Anzeige verschiedener Vorlagen basierend auf der Anmeldung eines Benutzers status. Dies wird in einem späteren Modul ausführlicher behandelt.
PasswordRecovery-Steuerelement
Das PasswordRecovery-Steuerelement wird verwendet, um vergessene Kennwörter von Benutzern einer ASP.NET-Anwendung abzurufen. Dies wird in einem späteren Modul ausführlicher behandelt.
LoginStatus
Das LoginStatus-Steuerelement zeigt die Anmeldung eines Benutzers status an. Dies wird in einem späteren Modul ausführlicher behandelt.
LoginName
Das LoginName-Steuerelement zeigt den Benutzernamen eines Benutzers an, nachdem er bei einer ASP.NET-Anwendung angemeldet wurde. Dies wird in einem späteren Modul ausführlicher behandelt.
Createuserwizard
Der CreateUserWizard ist ein konfigurierbarer Assistent, mit dem Benutzer ein ASP.NET Mitgliedschaftskonto für die Verwendung in einer ASP.NET-Anwendung erstellen können. Dies wird in einem späteren Modul ausführlicher behandelt.
ChangePassword
Mit dem ChangePassword-Steuerelement können Benutzer ihr Kennwort für eine ASP.NET-Anwendung ändern. Dies wird in einem späteren Modul ausführlicher behandelt.
Verschiedene WebParts
ASP.NET 2.0 wird mit verschiedenen Webparts ausgeliefert. Diese werden in einem späteren Modul ausführlich behandelt.
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