Inhalt
Vorwort
1 Wie .NET und ASP.NET funktionieren
2 Installation
3 Hinweise zu VB.NET
4 »Hallo, Welt!« – Ein ASP.NET-Crashkurs
5 Die Page-Klasse
6 HTML-Serversteuerelemente
7 Validierung von Anwendereingaben
8 Webserversteuerelemente
9 Webserversteuerelemente für die Darstellung von Listen
10 Webserversteuerelemente selbst erstellen
11 Der Status von Seiten, Sitzungen und Applikationen
12 ASP.NET und Datenbanken
13 »Wer darf was?« ASP.NET und Sicherheit
14 Webanwendungen erstellen und konfigurieren
15 Leistungssteigerung durch Caching
16 Web Services
A Anhang
Index
Download (ca 14,3 MB)
Buch bestellen (29,90 EUR)
Ihre Meinung?@
<< zurück | Galileo Computing / <openbook> / Einstieg in ASP.NET | vor >>
Einstieg in ASP.NET von Matthias Lohrer
| Kapitel 5 Die Page-Klasse
|  | 5.1 Der Lebenszyklus einer aspx-Seite
|  |  | 5.1.1 Lebenszyklus beim ersten Aufruf
|  |  | 5.1.2 Lebenszyklus bei einem Postback
|  |  | 5.1.3 In Page_Load die Validierung ausführen
|  | 5.2 Die Code-Behind-Technologie
|  |  | 5.2.1 Die aspx-Seite mit der Code-Behind-Datei verknüpfen
|  |  | 5.2.2 Die Code-Behind-Datei erstellen
|  | 5.3 Die Page-Direktive
|  | 5.4 Die Controls-Auflistung
# Kapitel 5 Die Page-Klasse Die Page-Klasse bildet den Hintergrund, auf dem die gesamte ASP.NET-Programmierung stattfindet. Jede Seite ist ein Page-Objekt. Am Ende des Crashkurses aus dem vorangegangenen Kapitel haben Sie ein kleines Skript erstellt, das einen Namen entgegennimmt und den Anwender anschließend mit seinem Namen begrüßt. Wenn der Anwender jedoch OK anklickt, ohne einen Namen einzugeben, erscheint eine Fehlermeldung. Hier noch einmal der komplette Code:
    <!-- name02.aspx -->
    <%@ Page Language="VB" Debug="True" Strict="True"  %>
    <script runat="server">
    Sub Page_Load (ByVal Sender As Object, _
                   ByVal E As EventArgs)
       If IsPostBack Then
          Page.Validate
          If IsValid Then
             meldung.Text = "Hallo, " & txtName.Value
          End If
       End If
    End Sub
    </script>
    <html><head><title>Begrüßung</title></head>
    <body><h1>Begrüßung</h1>
    <form runat="server">
    Wie heißen Sie?
    <br><br>
    <input runat="server" id="txtName" type="text" >
    <asp:RequiredFieldValidator
         id="reqTxtName"
         ControlToValidate="txtName"
         Display="dynamic"
         runat="server">
         Bitte geben Sie hier Ihren Namen ein.
    </asp:RequiredFieldValidator>
    <br><br>
    <input runat="server" type="submit" value=" OK " >
    <br><br>
    <asp:Label id="meldung" runat="server" />
    </form></body></html>
Vielleicht geht es Ihnen damit so wie mir am Anfang meiner Beschäftigung mit ASP.NET. Es wird zwar intuitiv einigermaßen klar, was hier abläuft, aber im Detail bleibt es ein einziges Rätsel. Die Funktionsweise dieser Seite soll deshalb genauer nachvollzogen werden. Dabei lernen Sie den zentralen Grundbaustein von ASP.NET näher kennen: Die Page-Klasse. Die Page-Klasse nimmt innerhalb von ASP.NET eine Schlüsselfunktion ein. Für den Webserver ist jede aspx-Seite eine Instanz der Klasse System.Web.UI.Page. Von der Page-Klasse ausgehend können Sie auf jedes Objekt zugreifen, das ASP.NET zu bieten hat. Weil das Page-Objekt so zentral und vielseitig ist, können viele Merkmale dieser Klasse in diesem Kapitel nur kurz erwähnt werden. Genauer erläutert werden sie in den folgenden Kapiteln. Zugespitzt ließe sich sagen: Um die ASP.NET-Programmierung zu erlernen, reicht es aus, lediglich die Page-Klasse gründlich kennen zu lernen. Diese Klasse bietet so viele Ansatzpunkte für alle Aspekte der Webprogrammierung, dass alle Kapitel dieses Buches in irgendeiner Weise mit der Page-Klasse zu tun haben. Die Eigenschaft Cache der Page-Klasse bietet beispielsweise Zugriff auf das Cache-Objekt, über das jede Applikation verfügt. Das ist das Thema von Kapitel 15, Leistungssteigerung durch Caching. Die Eigenschaft Session bietet Zugriff auf das HttpSessionState-Objekt, das der aktuellen Sitzung zugeordnet ist. Näheres dazu erfahren Sie in Kapitel 11, Der Status von Seiten, Sitzungen und Applikationen. Daten, die die ganze Webanwendung betreffen, werden in einem Objekt der Klasse HttpApplicationState gespeichert. Dieses Objekt erreichen Sie über die Application-Eigenschaft der Page-Klasse. Details dazu werden in den Kapiteln 11 und 15 erläutert. Und so geht es weiter mit jedem Thema dieses Buches und mit allem, was ASP.NET zu bieten hat. Tabelle 5.1 listet die Eigenschaften und einige Methoden der Page-Klasse auf.
Eigenschaften
Application | HttpApplicationState | Das Application-Objekt
Cache | Cache | Das aktuelle Cache-Objekt
ClientTarget | String | Deaktiviert die automatische Erkennung von Browserfunktionen
Controls | ControlCollection | Auflistung der Control-Objekte, aus denen diese Seite besteht
EnableViewState | Boolean | Bei True (Standard) behält die Seite ihren Anzeigestatus und den Status der enthaltenen Steuerelemente
ErrorPage | String | Fehlerseite, zu der umgeleitet wird, wenn eine unbehandelte Ausnahme auf der Seite auftritt
ID | String | Eindeutiger Bezeichner
IsPostBack | Boolean | True, wenn die Seite als Antwort auf ein Postback geladen wird
IsValid | Boolean | True, wenn die Überprüfung der Seite durch die Validierungssteuerelemente erfolgreich war
Page | Page | Die Page-Instanz selbst
Request | HttpRequest | Das Request-Objekt der aktuellen Anforderung
Response | HttpResponse | Das aktuelle Response-Objekt
Server | HttpServerUtility | Das aktuelle Server-Objekt. Bietet beispielsweise Zugriff auf die HtmlEncode- und MapPath-Methode
Session | HttpSessionState | Die aktuelle Sitzung
SmartNavigation | Boolean | True, wenn die intelligente Navigation aktiviert ist. Wird meist über die Page-Direktive gesetzt
TemplateSourceDirectory | String | Das virtuelle Verzeichnis dieser Seite
Trace | TraceContext | Das aktuelle TraceContext-Objekt
User | User | Bietet Informationen zum Benutzer
Validators | ValidatorCollection | Auflistung aller Validierungssteuerelemente
Visible | Boolean | True, wenn die Seite dargestellt werden soll
Methoden (Auswahl)
DataBind | Führt die Datenbindungen für alle datengebundene Steuerelemente dieser Seite aus.
MapPath | Ruft den physischen Pfad ab, auf den ein absoluter bzw. relativer virtueller Pfad verweist.
ResolveUrl (von Control geerbt) | Löst einen relativen URL in einen absoluten URL auf der Basis des Wertes auf, der an die TemplateSourceDirectory-Eigenschaft übergeben wurde. Der zurückgegebene URL ist für die Verwendung durch den Client bestimmt und enthält ggf. den Sitzungscookie.
Validate | Weist alle Validierungssteuerelemente auf der Seite an, die Validierung durchzuführen
Tabelle 5.1 Eigenschaften und einige Methoden der Klasse Page ## 5.1 Der Lebenszyklus einer aspx-Seite Beim ersten Aufruf einer aspx-Seite bemerken Sie im Browser eine gewisse Verzögerung. Eine aspx-Seite enthält verwalteten Code (managed Code), der von der Common Language Runtime verarbeitet wird. Beim ersten Aufruf tritt daher der Just-in-Time-Compiler in Aktion, der die Seite kompiliert. Das verursacht die Verzögerung. Bei weiteren Aufrufen steht die kompilierte Version bereits zur Verfügung. Weil der JIT-Compiler beim erneuten Aufruf einer Seite die Seite nicht nochmals kompilieren muss, werden weitere Aufrufe erheblich schneller abgearbeitet. Jedes Mal, wenn eine aspx-Seite vom Webserver angefordert wird, muss der Webserver die Seite laden, die Werte initialisieren, die Seite ausführen, zum Browser senden und wieder entladen. Diese Schritte bilden den Lebenszyklus einer Seite. Bei einem Postback fallen zusätzliche Schritte an. Diese Arbeit fällt auf jeden Fall an, unabhängig davon, ob die Seite vorher noch kompiliert werden muss oder nicht. ### 5.1.1 Lebenszyklus beim ersten Aufruf Beim ersten Aufruf einer Seite laufen folgende Schritte ab: 1. Init-Ereignis Den Anfang bildet das Init-Ereignis. Hier werden solche Einstellungen initialisiert, die für die ganze Lebenszeit der eingehenden Anforderung benötigt werden. 2. Load-Ereignis In dieser Phase wird der Baum aus Steuerelementen aufgebaut. Die erforderlichen Daten werden z. B. durch Datenbankabfragen ermittelt. 3. PreRender-Ereignis Dieses Ereignis bietet die letzte Möglichkeit, vor der Ausgabe Änderungen vorzunehmen. 4. SaveViewState-Methode Der ViewState-String wird erstellt. 5. Render-Methode Die Ausgabe an den Client wird generiert. 6. Dispose-Methode Ressourcen werden freigegeben. 7. UnLoad-Ereignis Das Objekt wird entladen. ### 5.1.2 Lebenszyklus bei einem Postback Bei einem Postback werden zusätzliche Schritte durchlaufen, so dass sich diese Abfolge ergibt: 1. Init-Ereignis 2. LoadViewState-Methode Der ViewState wird geladen. 3. LoadPostData-Methode Die Formulardaten werden verarbeitet. 4. Load-Ereignis 5. RaisePostDataChangedEvent-Methode Wenn sich Statusänderungen zum vorhergehenden Status ergeben, wird diese Methode ausgeführt. 6. RaisePostBackEvent-Methode Das Ereignis, das im Client den Postback verursacht hat, wird jetzt behandelt. 7. PreRender-Ereignis 8. SaveViewState-Methode 9. Render-Methode 10. Dispose-Methode 11. UnLoad-Ereignis Die Ereignisse und Methoden, die den Lebenszyklus einer aspx-Seite bilden, können Sie mit selbst definierten Prozeduren überschreiben. In den meisten Fällen werden aber alle serverseitigen Aktionen in der Page_Load-Prozedur zusammengefasst. In diesem Stadium wird der Baum aus Steuerelementen, aus dem eine aspx-Seite besteht, komplett aufgebaut und Sie können entsprechende Einstellungen vornehmen. Diesen üblichen Weg geht auch name02.aspx. Wenn Sie in der Page-Direktive das Attribut trace="true" hinzufügen, zeigt ASP.NET unterhalb der Seite zahlreiche Informationen an, die die Analyse der Seite ermöglichen. Der Abschnitt Überwachungsinformationen (siehe Abbildung 5.1) listet unter anderem diesen Lebenszyklus auf und verzeichnet für jeden Schritt die Dauer der Ausführung. Hier klicken, um das Bild zu Vergrößern Abbildung 5.1 Mit trace="true« in der Page-Direktive wird der Lebenszyklus der Seite bis zur Stufe Render dargestellt. ### 5.1.3 In Page_Load die Validierung ausführen
    Sub Page_Load (ByVal Sender As Object, _
                   ByVal E As EventArgs)
       If IsPostBack Then
          Page.Validate
          If IsValid Then
             meldung.Text = "Hallo, " & txtName.Value
          End If
       End If
    End Sub
In der Beispielseite name02.aspx prüft die Prozedur Page_Load anhand der IsPostBack-Eigenschaft der Page-Klasse zunächst, ob ein Postback vorliegt. Wenn nicht, dann gibt es hier nichts zu tun, und die Seite wird einfach angezeigt. Bei einem Postback veranlasst die Prozedur mit der Methode Page.Validate, dass die Validierungssteuerelemente der Seite die Überprüfungen durchführen. Anschließend kann die Page-Eigenschaft IsValid ausgewertet werden. Wenn die Validierung erfolgreich war, wird die Hallo, Soundso-Meldung ausgegeben. Wenn die Validierung scheitert, dann ist innerhalb der Page_Load-Prozedur nichts mehr zu tun. Für die Darstellung der Fehlermeldung sorgt in diesem Fall das Validierungssteuerelement selbst. Vielleicht kommen Sie auf die Idee, in der Page_Load-Prozedur auch den Else-Zweig auszufüllen, der ausgeführt wird, wenn die Seite nicht gültig ist, etwa so:
    Sub Page_Load (ByVal Sender As Object, _
                   ByVal E As EventArgs)
       If IsPostBack Then
          Page.Validate
          If IsValid Then
             meldung.Text = "Hallo, " & txtName.Value
          Else
             meldung.Text = "Bitte einen Namen eingeben."
          End If
       End If
    End Sub
Achtung Wenn Sie diese Version testen, werden Sie aber mit hoher Wahrscheinlichkeit eine Überraschung erleben. Wenn Sie zunächst korrekt einen Namen, z. B. Hugo, eingeben, erscheint die Meldung Hallo, Hugo. Anschließend löschen Sie den Eintrag im Textfeld und klicken wieder auf OK. Danach steht zwar neben dem Eingabefeld in roter Schrift der Hinweis Bitte geben Sie hier Ihren Namen ein. Unter der OK-Schaltfläche steht aber noch immer die Begrüßung Hallo, Hugo. Wieso wurde der Else-Zweig bei der Validierung nicht durchlaufen und der Meldungstext entsprechend geändert?
Des Rätsels Lösung besteht darin, dass in diesem Fall noch gar kein Postback zum Server stattgefunden hat, sondern die clientseitige JavaScript-Funktion tätig gewesen ist, die das Validierungssteuerelement automatisch generiert hat. Diese clientseitige Funktion überprüft nur das ihr zugeordnete Steuerelement. Sie übersetzt aber nicht die Page_Load-Prozedur in JavaScript, was auch nicht funktionieren würde. Und falls die clientseitige Validierung scheitert, findet erst gar kein Postback statt. Hier klicken, um das Bild zu Vergrößern Abbildung 5.2 Die clientseitige JavaScript-Routine wird vor dem Postback ausgeführt. Solange JavaScript im Browser aktiviert ist, werden nur gültige Seiten zum Server geschickt, so dass der Zweig für ungültige Seiten innerhalb von Page_Load nie ausgeführt wird. Wenn Sie diesen Zweig dennoch ausführen möchten, müssten Sie im Browser JavaScript deaktivieren. Nur dann erreichen auch ungültige Seiten den Server, und er kann entsprechend reagieren. In Kapitel 7, Validierung von Anwendereingaben, erhalten Sie genauere Informationen zu diesen Zusammenhängen. Ich habe bereits jetzt darauf hingewiesen, weil dieses undurchsichtige Verhalten am Anfang Verwirrung erzeugen kann.
<< zurück | <top> | vor >>
Zum Katalog
Einstieg in ASP.NET bestellen
Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen? Ihre Meinung

.NET-Bibliothek
| Einstieg in VB.NET
| VB.NET
| Einstieg in C#
| Visual C#
| VB.NET und Datenbanken

Empfehlung
| Einstieg in XML

Shopping
Versandkostenfrei bestellen in Deutschland und Österreich Info

MyGalileo
Der Service für registrierte Leser: Info

Copyright © Galileo Press GmbH 2003
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

[Galileo Computing]
Galileo Press GmbH, Gartenstraße 24, 53229 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de