Das Web Forms- Programmiermodell

Kapitel 4 Das Web Forms- Programmiermodell In diesem Kapitel: ASP.NET-Webanwendungen 48 Client-Server-Modell 50 ASP.NET-Serversteuerelemente 52 Ereignismodell 60 Seitenübergänge 71 Trennung von Gestaltung und Programmcode 88 Kompilierung und Programmiersprachen 90 Verbreitung von ASP.NET-Webanwendungen 92 Steuerelementtypen 93 Zusammenfassung 96 47

48 Kapitel 4: Das Web Forms-Programmiermodell ASP.NET beinhaltet ein neues Programmiermodell für Webseiten im Vergleich zu PHP, Java Server Pages (JSP) oder dem klassischen ASP. Das ASP.NET-Programmiermodell wird als Web Form-Programmiermodell bezeichnet. Ein Web Form ist eine.aspx-seite, die neben konventionellem HTML-Code auch so genannte Serversteuerelemente beinhaltet. Das ASP.NET Page Framework ist die Infrastruktur, die Web Forms ausführt und Dienste für die Verwendung in Web Forms bereitstellt. Das Web Forms-Programmiermodell in ASP.NET ist objektorientiert und ereignisbasiert (ähnlich der Entwicklung von Desktop-Anwendungen mit Visual Basic 6.0 bzw. Windows Forms oder der Windows Presentation Foundation (WPF) in.net. WICHTIG Ein Web Form enthält nicht notwendigerweise ein Eingabeformular. Web Form ist vielmehr der Oberbegriff für alle Webseiten, die ASP.NET verwenden. ASP.NET-Webanwendungen Ein Webprojekt kann in ASP.NET aus folgenden Elementen bestehen: Dynamischen Webseiten (Web Forms) (.aspx-dateien) mit zugehöriger Hintergrundcodedatei (.aspx.vb,.aspx.cs etc.) Webdiensten (Webservices) (.asmx-dateien) mit zugehöriger Hintergrundcodedatei (.asmx.vb,.asmx.cs etc.) Statischen Webseiten (.htm-dateien) Statischen Grafiken und audiovisuellen Medienelementen (z. B..gif,.jpg,.wav,.pdf etc.) Eigenständigen Codedateien (Stand-alone Class Files /.vb,.cs,.js) Einer Codedatei für globale Ereignisse (global.asax) mit zugehöriger Hintergrundcodedatei (.asax.cs,.asax.vb etc.) Programmcode in kompilierter Form (Softwarekomponenten aus der.net-klassenbibliothek oder andere.net-softwarekomponenten) Benutzer-Steuerelementen (engl. User Controls /.ascx-dateien) mit zugehöriger Hintergrundcodedatei für Webservices (.ascx.cs,.ascx.vb etc.) ASP.NET-HTTP-Handler (.ashx) Konfigurationsinformationen in XML-Dateien (.config) Ressourcendateien (.resx) Sonstigen Daten in Datenbanken, Text- und/oder XML-Dateien Mit Ausnahme der globalen Anwendungsdatei können alle Elemente mehrfach in einer einzigen Webanwendung vorkommen.

ASP.NET-Webanwendungen 49 Web-Anwendung (ASP.NET) Zu kompilierender Quellcode Nicht zu kompilierende Bestandteile Webseiten N ASPX- Datei Code- Behind- Datei Webseiten N Statische Datei (.htm,.gif,.jpg, etc.) Webdienste N ASMX- Datei Code- Behind- Datei Sonstiger Code N Komponente aus der.net-klassenbibliothek N Sonstige.NET-Softwarekomponente Sonstige Codedateien 1 N Konfigurationsdaten N N ASAX- Datei Code- Behind- Datei Code- Dateien Sonstige Daten N Web.config (XML) Datenbank N Web.sitemap (XML) Datendateien (.txt,.xml) Abbildung 4.1 Bestandteile einer ASP.NET-Webanwendung Verzeichnisstruktur Webanwendungen in ASP.NET besitzen eine bestimmte Verzeichnisstruktur zur Ablage von Dateien: Web Form-unabhängige Codedateien im /App_Code-Verzeichnis Kompilierte Codedateien im /bin-verzeichnis (für im Webprojekt referenzierte Assemblies und für die kompilierten Assemblies des Webprojekts) Datenbankdateien im Verzeichnis /App_Data Verzeichnisse /App_GlobalResources und /App_LocalResources mit (sprachspezifischen) Ressourcendateien Verzeichnis /App_Browsers mit Informationen zu Webbrowsern Verzeichnis /App_Themes mit.css- und.skin-dateien Verzeichnis /App_Webreferences mit WSDL-Dateien und Proxyklassen Mit Ausnahme des /App_Themes-Verzeichnisses leiten die IIS die Inhalte der Sonderordner nicht direkt an den Client weiter. Der Inhalt dieser Verzeichnisse steht nur der Anwendung selbst zur Verfügung.

50 Kapitel 4: Das Web Forms-Programmiermodell Beim Anlegen der Sonderverzeichnisse unterstützt Sie Visual Studio durch das Kontextmenü Neuer Ordner (Add Folder) im Projektmappen-Explorer. Einige Sonderordner werden auch automatisch durch andere Funktionen der Entwicklungsumgebung bzw. durch die webbasierte Konfigurationsschnittstelle von ASP.NET angelegt. Abgrenzung zwischen Webanwendungen Die Frage, was genau eine ASP.NET-Webanwendung ist, genauer gesagt, wo sie anfängt und aufhört, ist eine kurze Betrachtung wert. Hier sind verschiedene Sichten zu unterscheiden: Zur Laufzeit: In den Internet Information Services (IIS) gehören alle Seiten, die in der gleichen IIS- Anwendung laufen, zu einer einzigen ASP.NET-Webanwendung. Eine IIS-Anwendung ist eine Funktion des Webservers zur Abgrenzung von dynamischen Inhalten. In den IIS 6.0 kann man für jede IIS-Anwendung einen eigenen Anwendungspool festlegen und damit einen eigenen Webserver-Arbeitsprozess erzeugen. Zur Laufzeit besitzen zwei ASP.NET-Anwendungen keine gemeinsame Infrastruktur, das heißt keine gemeinsamen Sitzungen und auch keine gemeinsame Authentifizierung. Die Übergabe von Werten und die Authentifizierung müssten manuell erfolgen. Zur Entwicklungszeit: Die Entwicklungsumgebung Visual Web Developer (VWD), die es als eigenständige Anwendung oder als Teil von Visual Studio (ab Version 2005) gibt, kennt zwei unterschiedliche Projektmodelle: Das Websitemodell und das Webanwendungsmodell. Beim Websitemodell gehört alles, was sich unterhalb eines bestimmten physikalischen Verzeichnisses im Dateisystem oder unterhalb eines Wurzelordners in den IIS befindet, zur ASP.NET-Webanwendung. Der VWD kennt aber die Restriktion der IIS bezüglich Webanwendungen und blendet daher den Inhalt von Verzeichnissen, die eigene IIS- Anwendungen sind, aus. Im Webanwendungsmodell kann der Entwickler selbst explizit Dateien in ein Projekt aufnehmen oder ausschließen. Der tatsächliche Ordnerinhalt ist irrelevant. Client-Server-Modell Abbildung 4.2 zeigt eine grobe Sicht auf das ASP.NET-Programmiermodell: Der Webclient (Webbrowser) stellt eine HTTP-Anfrage an den Webserver. Der Webserver leitet die Anfrage an die ASP.NET-Seite weiter. Die ASP.NET-Seite besteht auf dem Webserver aus HTML-Code, XML-Code und.net-programmcode. Das ASP.NET Page Framework führt die Seite aus und erzeugt daraus eine HTTP-Antwort. Die HTTP-Antwort enthält nur HTML, Cascading Style Sheets (CSS), JavaScript und Zustandsdaten (z. B. in Form von Cookies). Der Browser stellt die HTML-Seite dar und führt den JavaScript-Code aus.

Client-Server-Modell 51 Die vorgenannten Punkte unterscheiden sich noch nicht fundamental von anderen Rahmenwerken zur Webserverprogrammierung. Die interessanten Details liegen in der Ausführung der ASP.NET-Seite und der Erzeugung der Ausgabe (Umsetzung in HTML, alias Rendering). Dies wird im folgenden Abschnitt besprochen. Webclient (Browser) HTTP-Anfrage ASP.NET-fähiger Webserver Webseite HTML + CSS + JavaScript + Zustandsdaten HTTP-Antwort Generierung "Adaptive Rendering" ASP.NET-Webseite (.aspx) HTML + XML +.NET-Programmcode ASP.NET Page Framework Abbildung 4.2 Client-Server-Architektur unter Einsatz von ASP.NET ASP.NET und der Client ASP.NET ist primär eine serverseitige Webtechnologie, das heißt die erstellte ASP.NET-Anwendung wird für den Webserver erstellt und dort auch ausgeführt. Der serverseitige Charakter von ASP.NET kann gar nicht oft genug betont werden, denn immer wieder werden bei Vorträgen und in Newsgroups Fragen gestellt, wie man denn mit ASP.NET drucken oder ein neues Browserfenster öffnen kann. Die Antworten auf diese Fragen sind immer gleich: Grundsätzlich kann man das nicht mit ASP.NET erledigen, denn ASP.NET kann den Browser oder den Clientcomputer (auf dem der Browser läuft) nicht steuern, sondern nur Inhalte erzeugen, die der Browser darstellen kann. ASP.NET könnte Druckaufträge höchstens für einen von dem Webserver erreichbaren Netzwerkdrucker in einem Intranet erzeugen. ASP.NET kann nicht auf die Systemsteuerung oder die Programme des Clients zugreifen. Das ist auch so gewollt, denn ein Client im Web will vor Systemzugriffen durch den Webserver geschützt sein. ASP.NET erzeugt HTML- Code, der vom Browser verarbeitet wird. HTML selbst enthält keine dynamischen Elemente.

52 Kapitel 4: Das Web Forms-Programmiermodell Keine Regel ohne Ausnahme: ASP.NET kann aber neben HTML-Code auch Browser-Skriptcode (z. B. JavaScript) an den Client senden. Zum Teil erzeugt ASP.NET zusammen mit dem HTML-Code automatisch auch einige JavaScript-Funktionen. Der Entwickler hat die Möglichkeit, selbst eigenen JavaScript- Code auf dem Server zu generieren und an den Client zu senden. Einige Funktionen in ASP.NET funktionieren nicht oder nur eingeschränkt ohne JavaScript. Dazu gehören z. B. die Validatoren und das UpdatePanel-Steuerelement. Diese»Ausnahme«ändert aber nichts daran, dass man nicht erwarten darf, dass ASP.NET den Client komplett selbst steuern kann. ASP.NET-Serversteuerelemente Das Web Forms-Programmiermodell realisiert eine zusätzliche Abstraktionsebene bei der Webprogrammierung. Klassische ASP-Seiten beinhalten direkt HTML-Code (oder ein anderes Ausgabeformat). ASP.NET- Seiten beinhalten hingegen neben konventionellem HTML-Code auch spezielle Tags mit dem Attribut runat="server". Diese Tags werden als Serversteuerelemente (Web Server Controls) bezeichnet. WICHTIG In ASP.NET ist es auch weiterhin erlaubt, reines HTML sowie Render- und Display-Blöcke alternativ zu Serversteuerelementen zu verwenden. Diese Inhalte können dann aber nicht über ein Objekt auf der Serverseite verändert werden. Um die gesamte Seite objektorientiert manipulierbar zu machen, muss man die Serversteuerelemente Label oder PlaceHolder verwenden. Allerdings benötigen diese Serversteuerelemente mehr Rechenzeit als klassische ASP-Codeblöcke. Der Einsatz sollte daher wohl überlegt sein. Adaptive Rendering Serversteuerelemente werden nicht direkt an den Client übertragen, sondern auf dem Server findet zunächst eine Umwandlung statt. Es wird erst zur Laufzeit entschieden, ob das Ausgabeformat reines HTML ist oder HTML mit Skriptcode (Dynamic HTML) oder Wireless Markup Language (WML) oder Compact HTML (chtml).

ASP.NET-Serversteuerelemente 53 ASP/PHP/JSP/etc. Programmcode (Teil der.asp/.php/.jsp-seite) ASP.NET Programmcode (.aspx.vb oder Teil der.aspx-datei) Eigener Code...... gibt aus Eigener Code...... programmiert Webcontrol- Objekt Initialiisiert Quellcode (.asp) Seitenquellcode (.aspx) <HTML-Tag> <Serversteuerelement- Tag runat="server"> Generiert <HTML-Tag> Webserver <HTML-Tag> Webserver Ausgabeseite Ausgabeseite <HTML-Tag> <Tag> (browserspezifisch) <HTML-Tag> <HTML-Tag> Browser Browser Abbildung 4.3 Abstraktion durch Serversteuerelemente Aus jedem Serversteuerelement werden ein oder mehrere Tags generiert. Der Webbrowser enthält nur ihm bekannte Tags (und gegebenenfalls clientseitigen Skriptcode), weil alle Serversteuerelemente bereits auf der Serverseite in browserspezifische Tags umgesetzt werden. Dieser Umsetzungsvorgang wird Adaptive Rendering genannt. Beispielsweise wird aus dem Serversteuerelement <asp:textbox> bei der Umwandlung der HTML-Tag <input type=text>. Konventionelle HTML-Tags werden wie bisher ohne Verarbeitung auf dem Server an den Client übertragen.

54 Kapitel 4: Das Web Forms-Programmiermodell Microsoft hat für die wichtigsten HTML-Tags eigene Serversteuerelemente definiert, die sich dadurch auszeichnen, dass sie konsistenter sind als ihre Pendants aus der HTML-Welt. So sind z. B. <textbox> und <textarea> zu <asp:textbox> zusammengefasst. Neben einfachen Serversteuerelementen, die eine Eins-zueins-Abbildung zwischen Serversteuerelement und HTML-Tag realisieren, gibt es auch komplexe Serversteuerelemente, die in mehrere, möglicherweise sogar hunderte einzelne HTML-Tags umgesetzt werden. Beispiele dafür sind die Serversteuerelemente GridView (zur Ausgabe von Daten-Tabellen), TreeView (für eine Baumdarstellung) und Calendar (Kalender mit Auswahlmöglichkeit). Steuerelementobjekte versus Steuerelementtags Bei den Serversteuerelementen sind zwei Darstellungsformen zu unterscheiden: In der.aspx-seite werden Serversteuerelemente (Server Controls) repräsentiert durch Tags (Serversteuerelementtag, Server-Control-Tag, Server-Tag bzw. serverseitiger Tag) mit dem Attribut runat="server" und einem Präfix (standardmäßig asp:). Im Rahmen der serverseitigen Programmierung werden die Serversteuerelemente durch.net-objekte (Serversteuerelementobjekt oder Server Control Object) repräsentiert mit Attributen, Methoden und Ereignissen. In dem Serversteuerelementobjekt ist die Logik für das Adaptive Rendering hinterlegt. Ein Serversteuerelementobjekt ist eine Instanz einer von der Klasse System.Web.UI.Control abgeleiteten Klasse. Ein Web Form selbst ist eine von der Klasse System.Web.UI.Page abgeleitete Klasse. Sie wird auch als Seitenklasse bezeichnet. ACHTUNG Bei der Verwendung des englischen Begriffs»Page Class«ist zwischen einer Page Class und der Page Class (System.Web.UI.Page) genau zu unterscheiden. Steuerelementtags Die Deklaration eines Serversteuerelements innerhalb eines Web Forms wird immer in der folgenden Form vorgenommen: <asp:steuerelementtyp id="elementid" runat="server" Attribut1="Wert1" Attribut2="Wert2" /> Listing 4.1 Grundstruktur eines Serversteuerelements Die Attribute des Server-Tags sind keine Attribute von HTML-Tags, sondern vielmehr Attribute der zugehörigen Webserversteuerelement-Klasse. Wie ein Webserversteuerelement auf dem Client dargestellt wird, hängt einerseits vom Client selbst, andererseits von den programmierten Einstellungen ab. Beispielsweise kann ein TextBox-Steuerelement als <input>-tag oder als <textarea>-tag dargestellt werden, da der Code der.aspx-seite bei der Kompilierung unter Berücksichtigung der im Steuerelement eingestellten Attributwerte in entsprechendes HTML umgewandelt wird.

ASP.NET-Serversteuerelemente 55 Steuerelementobjekte Die Abbildung in Tabelle 4.1 stellt den Serversteuerelementtag und das Serversteuerelementobjekt für ein TextBox-Steuerelement gegenüber. Alle Attribute im Tag sind auch im Objekt vorhanden, mit Ausnahme von runat="server". Der Eigenschaftendialog zeigt alle Eigenschaftswerte, auch solche, die auf Standardwerten (z. B. Visible="true") beruhen. Standardwerte müssen im Tag nicht wiedergegeben werden. Quelltext Liste der Attribute des Objekts (dargestellt durch das Eigenschaftenfenster im VWD) <asp:textbox id="f_name" runat="server" Width="202px" BorderWidth="2px" ForeColor="Blue" Font-Names="Arial" Font-Italic="True" Font-Bold="True" Font Size="12pt"> Dr. Holger Schwichtenberg </asp:textbox> Tabelle 4.1 Quelltext eines Steuerelements versus VWD-Eigenschaftenfenster Verhalten bei Fehlern in den Tags Bei Fehlern in den Serversteuerelementtags ist ASP.NET unterschiedlich tolerant. Fehlende Anführungszeichen um die Attributwerte werden toleriert, ebenso spielt die Groß- und Kleinschreibung der Tag-Namen keine Rolle. Ungültige Tag-Namen und fehlende schließende Tags toleriert das ASP.NET Page Framework jedoch ab Version 2.0 im Gegensatz zu den Vorgängerversionen nicht mehr. Wenn man das Attribut runat="server" weglässt, ignoriert das ASP.NET Page Framework den Tag und sendet ihn unverändert zum Client. Hier besteht natürlich die Gefahr, dass man durch solche Fehler dem

56 Kapitel 4: Das Web Forms-Programmiermodell Benutzer Implementierungsdetails offenbart. Wenn beim Attribut runat etwas anderes als "server" angegeben wird, streikt der Compiler. Eine ASPX-Seite darf nur genau ein <form>-steuerelement enthalten. Bei Verstößen gegen diese Regel kommt es zum Laufzeitfehler:»Eine Seite darf nur ein einziges serverbasiertes Form-Tag haben.«(»a page can have only one server-side form tag.«) Die Groß- und Kleinschreibung ist beim Attribut Inherits in der @Page-Direktive genau einzuhalten, da ASP.NET die Hintergrundcodeklasse sonst nicht findet. Steuerelement Formular Texteingabefeld Liste von Optionsschaltflächen Auswahlfeld Kontrollkästchen Schaltfläche Tag <form id="form1" method="post" runat="server"> </form> <asp:textbox id="f_name" runat="server" Width="202px"> Schwichtenberg </asp:textbox> <asp:radiobuttonlist id="radiobuttonlist1" runat="server" RepeatDirection="Horizontal"> <asp:listitem Value="m">Männlich</asp:ListItem> <asp:listitem Value="w" Selected="True">Weiblich </asp:listitem></asp:radiobuttonlist> <asp:dropdownlist id="f_beruf" runat="server" Width="201px"> <asp:listitem Value="Student">Student</asp:ListItem> <asp:listitem Value="Professor">Professor</asp:ListItem> <asp:listitem Value="WissenschaftlicherMitarbeiter" Selected="True">WissenschaftlicherMitarbeiter</asp:ListItem> </asp:dropdownlist> <asp:checkbox id="checkbox1" runat="server" Text="Für Eintragung Rückbestätigung per E-Mail anfordern."> </asp:checkbox> <asp:button id="b_eintragen" runat="server" Text="Eintragen"> </asp:button> Tabelle 4.2 Beispiele für Serversteuerelemente

ASP.NET-Serversteuerelemente 57 Programmierung der Steuerelementobjekte Das Serversteuerelementobjekt wird durch die Tag-Deklaration in der Webseite initialisiert und durch den serverseitigen Programmcode im Folgenden manipuliert. Die generierte Ausgabe ist die Mischung aus in den Tags hinterlegten Vorgaben und dem Programmablauf. Der objektorientierte programmgesteuerte Zugriff auf den Inhalt der Webseite löst das sequenzielle Erzeugen von HTML-Quellcode ab, das im klassischen ASP und in verwandten Techniken wie PHP verwendet wird. Deklaration in der.aspx-seite (Serversteuerelementtags) Verwendung im Programmcode (Serversteuerelementobjekt) <asp:textbox id="vorname" runat="server"> kein Name eingetragen </asp:textbox> Vorname.Text = "Holger Schwichtenberg"; Steuerelementhierarchie (Objektbaum) Genau wie bei Windows Forms bilden die Steuerelemente einer Webseite in ASP.NET durch die Verschachtelung ein hierarchisches Objektmodell. An der Spitze des Objektmodells steht die von Page abgeleitete Seitenklasse. Die einzelnen Steuerelementobjekte sind in der Controls-Menge enthalten. Einige Steuerelemente bilden Container für andere Steuerelemente. Diese Containersteuerelemente besitzen wiederum untergeordnete Steuerelemente in ihrer Controls-Menge, sodass ein Objektbaum entsteht. Die direkte Programmierung mit dem Objektbaum wird im Buchteil G»Profiwissen«angesprochen. Im ASPX-Code gibt es drei Formen von Elementhierarchien: Einige Serversteuerelemente können beliebige Serversteuerelemente enthalten (z. B. beim Panel- Steuerelement). Andere Serversteuerelemente können ausgewählte Serversteuerelemente aufweisen. Beispielsweise enthalten die Steuerelemente DropDownList, ListBox, CheckBoxList und RadioButtonList Untersteuerelemente vom Typ ListItem. Serversteuerelemente können so genannte Vorlagen (Templates) enthalten, die wiederum beliebige andere Serversteuerelemente aufweisen (so z. B. beim Repeater-Steuerelement). Die Umsetzung dieser Beziehung in ein Objektmodell ist von Klasse zu Klasse unterschiedlich. <asp:listitem> wird abgebildet durch ein Attribut Item vom Typ System.Web.UI.WebControls.ListItemCollection. Ein Panel- Steuerelement dagegen enthält die Unterelemente in einer ControlCollection im Attribut Controls. Die Repeater-Klasse weist für jedes <Template>-Unterelement ein Unterobjekt auf. <asp:panel id="panel1" runat="server" Height="98px" Width="304px"> Inhalt <asp:textbox id="textbox2" runat="server"> </asp:textbox> <asp:label id="label3" runat="server"> Label </asp:label> </asp:panel> Listing 4.2 Verschachtelung von Serversteuerelementen am Beispiel des Panel-Steuerelements

58 Kapitel 4: Das Web Forms-Programmiermodell <asp:dropdownlist id="mengeproseite" runat="server"> <asp:listitem Value="0">Alle</asp:ListItem> <asp:listitem Value="20">20 pro Seite</asp:ListItem> <asp:listitem Value="40">40 pro Seite</asp:ListItem> </asp:dropdownlist> Listing 4.3 Verschachtelung von Serversteuerelementen am Beispiel des DropDownList-Steuerelements <asp:repeater id="ergebnisliste" runat="server" > <ItemTemplate> <asp:label id="label1" runat="server">inhalt</asp:label> <br> <asp:button id="button1" runat="server" Text="Button"></asp:Button> </ItemTemplate> </asp:repeater> Listing 4.4 Vorlagen in Serversteuerelementen am Beispiel des Repeater-Steuerelements Abbildung 4.4 zeigt einen Ausschnitt aus dem Objektbaum einer typischen Seite, hier dargestellt mithilfe des Visual Studio-Debuggers. Die Seite besteht aus einer Vorlage (Masterpage). In der Masterpage gibt es fünf Steuerelemente: Einen HTML-Kopftag (HtmlHead), ein Formular (HtmlForm) und drei statische Texte (LiteralControl). Abbildung 4.4 Beispiel für ein typisches Seitenobjektmodell einer ASP.NET-Webseite (dargestellt im Debugger von Visual Studio)

ASP.NET-Serversteuerelemente 59 Beispiel: ASP versus ASP.NET Anhand eines einfachen Beispiels kann der Unterschied in der Programmierung zwischen dem klassischen Erzeugen von HTML und der objektorientierten Programmierung in ASP.NET gezeigt werden. Die Anwendung erhöht den Wert in einem Textfeld bei jedem Rundgang um eins. Wenn die Zahl gerade ist, bekommt das Textfeld einen gelben, sonst einen grünen Hintergrund. Abbildung 4.5 Erhöhen eines Zählers in ASP und ASP.NET Lösung in ASP In der ASP-Implementierung sind Gestaltung und Programmcode ineinander verwoben. Der Programmcode erzeugt direkt HTML- bzw. CSS-Tags: <!--- Formulardefinition ASP --> <FORM id="form1" method="post"> <INPUT name="count1" type="text" value="<%=request("count1")+1%>" <%if Request("count1") mod 2 = 0 then%> style="background-color: yellow"> <%else%> style="background-color: greenyellow"> <%end if%> <BR> <INPUT type="submit" value="erhöhen (ASP)" name="submit1"> </FORM> Listing 4.5 Zähler in ASP Lösung in ASP.NET Zur Gegenüberstellung folgt nun die elegantere Lösung in ASP.NET, bei der nicht direkt HTML- oder CSS- Tags erzeugt werden. Vielmehr beeinflusst der Programmcode typisierte Objekte, die HTML und CSS entsprechend den Eigenschaften des jeweiligen Browsers erzeugen: <!--- Formulardefinition ASP.NET --> <FORM id="form2" method="post" runat="server"> <asp:textbox id="textbox1" runat="server">1</asp:textbox> <asp:button id="button1" runat="server" Text="erhöhen (ASP.NET)"></asp:Button> </FORM> <script runat="server"> ' === Ereignisbehandlung Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) _ Handles Button1.Click TextBox1.Text = CInt(TextBox1.Text) + 1 If CInt(TextBox1.Text) Mod 2 = 0 Then TextBox1.BackColor = System.Drawing.Color.Yellow Else TextBox1.BackColor = System.Drawing.Color.GreenYellow End If </script> Listing 4.6 Zähler in ASP.NET

60 Kapitel 4: Das Web Forms-Programmiermodell Ereignismodell Dieser Abschnitt erläutert das Ereignismodell von ASP.NET. Ereignisarten und Ereignisverarbeitung Die Benutzerschnittstellensteuerung liegt bei ASP.NET in serverseitigen Ereignisbehandlungsroutinen für die Serversteuerelementereignisse. Es gibt zwei Arten von Ereignissen: Seitenereignisse, die im Rahmen der verschiedenen Verarbeitungsschritte einer ASPX-Datei auf dem Server ausgelöst werden (z. B. Page_Load(), TextBox1_PreRender()) Steuerelementereignisse, die Aktionen und Zustandsänderungen (z. B. neuen Werten) auf dem Client entsprechen (beispielsweise Button1_Click(), Textbox1_TextChanged()) Die Steuerelementereignisse sind für ASP.NET nur Pseudoereignisse, weil es kein echtes Ereignissystem zwischen Client und Server gibt. Ein Webserver erhält von dem Webbrowser im Rahmen einer HTTP-Anfrage keine Ereignisse, sondern nur den Inhalt der Eingabefelder. Außerdem findet eine Datenübertragung vom Browser an den Server nur im Rahmen einer erneuten HTTP-Anfrage (Roundtrip) zum Server statt. Ein Rundgang wird normalerweise durch einen Klick auf eine Submit-Schaltfläche (HTTP-GET oder HTTP-POST) oder durch den Klick auf einen Link (HTTP-GET) ausgelöst nicht bei jeder Änderung eines Eingabefeldes. Das ASP.NET Page Framework analysiert den Inhalt der eingehenden HTTP-Anfrage und erzeugt daraus (zeitverzögert) Pseudoereignisse auf dem Server für Änderungen, die vorher im Client erfolgt sind. Aus der Sicht des Programmcodes sind diese Pseudoereignisse echte.net-ereignisse. Webclient (Browser) HTTP-Anfrage HTTP-Anfrage URL HTTP Header HTTP Inhalt ASP.NET Page Framework Ereignisse Eigener Programmcode Webseite Objektmodell ASPX-Seite Control HTML + CSS + JavaScript + Zustandsdaten HTML XML Control Control Control Control Abbildung 4.6 Erzeugung von Ereignissen und Seitenobjektmodell durch das ASP.NET Page Framework Postback-Modell Zum Web Forms-Programmiermodell gehört es, dass alle Rundgänge auf einem HTTP-POST basieren man spricht dabei von einem Postback. Durch clientseitigen JavaScript-Code wird erreicht, dass auch ein Klick auf einen Link oder die Wertänderung in einem Eingabefeld einen Postback anstoßen können. Ob ein

Ereignismodell 61 Serversteuerelement bei einem Klick oder einer Wertänderung einen Postback auslöst, ist durch das so genannte Sendeverhalten konfigurierbar (Attribut AutoPostBack). Für Steuerelemente wie Texteingabefelder, die in HTML normalerweise keinen Postback auslösen, wird dieser durch ein kleines JavaScript hervorgerufen ( dopostback()). Abbildung 4.7 zeigt ein Szenario, bei dem ein Postback durch einen Klick auf Button1 ausgelöst wird. Die zuvor vorgenommenen Änderungen an Textbox1 und List1 bemerkt der Server erst nach dem Rundgang. Der Server erhält keine Ereignismeldungen im eigentlichen Sinne, weil es in HTML/HTTP keine solchen Ereignismeldungen vom Client an den Server gibt. Der Server bekommt lediglich den aktuellen Inhalt der Eingabefelder, die er mit dem letzten Inhalt der Felder (die im versteckten Feld Viewstate gespeichert werden) vergleicht. Dadurch kann das ASP.NET Page Framework erkennen, welche Aktionen auf dem Client ausgeführt wurden. Es löst dann aber zeitverzögert die entsprechenden Ereignisbehandlungsroutinen Textbox1_TextChanged(), List1_SelectedIndexChanged() und Button1_Click() aus. Selbstverständlich kann so nicht bemerkt werden, ob ein Benutzer einen Wert in einem Eingabefeld ändert und dann vor dem Absenden den alten Wert wiederherstellt. Da aus der Sicht des Servers nichts passiert ist, wird kein Ereignis auf dem Server ausgelöst. In Dynamic HTML würden in diesem Fall zwei Änderungsereignisse auf dem Client ausgelöst. HINWEIS ASP.NET täuscht eine Ereignisinfrastruktur, wie man sie aus Windows Forms oder WPF kennt, nur vor. Die meisten Ereignisse in ASP.NET kann man daher auch»pseudoereignisse«nennen. Browser Webserver (C) Holger@Schwichtenberg.de 2002-2005 HTTP Request Seite.aspx (Quelltext) Neuer Inhalt Neue Auswahl Klick "Postback" Textbox1 Textbox2 List1 Button1 TEXT/HTML HTTP Response <HTML><BODY> <form method="post> <input type="text" id="textbox1"> <input type="text" id="textbox2">... <input type="submit" id="button1"> </form> </BODY></HTML> TEXT/HTML <%@ Page Codebehind= Seite.aspx.vb Inherits= Webname.Seite > <HTML>... <asp:textbox id="textbox1" runat="server"> <asp:textbox id="textbox2" runat="server"> <asp:dropdownlist id="list1" runat="server"> <asp:button id="button1" runat="server" Text="Button">... </HTML> Initialisierung <SCRIPT runat="server"> Sub Page_Load() Sub TextBox1_TextChanged() Sub TextBox2_TextChanged() Sub List1_SelectedIndexChanged() Sub Button1_Click() Sub Page_Unload() Aufruf </SCRIPT> HTTP Request Abbildung 4.7 Postback-Modell Die Anzahl der Serversteuerelementereignisse ist typischerweise deutlich geringer als die der clientseitigen DHTML-Ereignisse. Dies ist auch klar, denn Ereignisse wie MouseDown(), KeyPressed() oder Enter() auf dem

62 Kapitel 4: Das Web Forms-Programmiermodell Server zu behandeln, ergibt angesichts der Zeit, die ein Rundgang zum Server benötigt, keinen Sinn. Derartige Ereignisse müssen weiterhin durch Dynamic HTML (DHTML) auf dem Client behandelt werden. Überhaupt würde der Server von diesen Ereignissen nur durch den Einsatz von zusätzlichen Clientskripts erfahren, denn diese Ereignisse führen ja nicht notwendigerweise zu einer Änderung des Inhalts, die der Server bemerken würde. Ereignis Typ Beschreibung Load() Seitenereignis Ereignis vor der Generierung des HTML-Codes für ein Steuerelement UnLoad() Seitenereignis Ereignis nach der Generierung des HTML-Codes für ein Steuerelement Click() Steuerelementereignis mit automatischem Postback Klick auf eine Schaltfläche TextChanged() Steuerelementereignis, optional mit Postback Beenden der Eingabe in ein Textfeld SelectedIndexChanged() Steuerelementereignis, optional mit Postback Ändern der Auswahl in einem Auswahlfeld CheckedChanged() Steuerelementereignis, optional mit Postback Änderung des Zustands einer CheckBox Tabelle 4.3 Wichtige Webcontrol-Ereignisse als Beispiel: Alle Nicht-Postback-Ereignisse können optional zu Postback-Ereignissen werden HINWEIS Während in ASP.NET 1.x ein Postback immer auf dieselbe Seite erfolgt, unterstützt ASP.NET seit Version 2.0 zusätzlich so genannte Cross-Page-Postbacks, mit denen ein Übergang zu einer anderen Seite möglich ist. Ereignisbindung ASP.NET bietet drei Möglichkeiten, ein Ereignis an eine Ereignisbehandlungsroutine zu binden: Implizit über Namenskonventionen mit der AutoEventWireup-Option aus der @Page-Direktive Explizit im Programmcode Explizit in einem On???-Attribut im Steuerelementtag, wobei die drei Fragezeichen für den Ereignisnamen stehen, z. B. OnClick="C_Absenden_Click" Programmcode On-Attribut Ereignisbindung mit Namenskonvention (AutoEventWireup) Anwendbar für Seitenereignisse Ja Nein Ja Anwendbar für Steuerelementereignisse Ja Ja Nein Name der Ereignisbehandlungsroutine Beliebig Beliebig Klassenname_Ereignisname Mehrfach-Ereignisbindung Ja Nein Nein Verwendbar in ASPX-Seite Ja Ja Ja Verhalten, wenn sowohl in der ASPX- Beide werden ausgeführt Wird nur in ASPX-Seite Wird nur in ASPX-Seite ausgeführt

Ereignismodell 63 Seite als auch in der Hintergrundcodeseite Routine definiert Programmcode On-Attribut Ereignisbindung mit Namenskonvention (AutoEventWireup) ausgeführt Standardverfahren in Visual Basic C# für Steuerelementereignisse C# für Seitenereignisse Tabelle 4.4 Überblick über die Unterschiede zwischen den vier Ereignisbehandlungsbindungsverfahren HINWEIS Das von der Webentwicklungsumgebung Visual Web Developer (VWD) verwendete Verfahren zur Ereignisbindung, wenn Sie über die Entwicklungsumgebung ein Ereignis erstellen, ist abhängig von der Sprache. In Visual Basic wird Programmcode verwendet, C# nutzt für Seitenereignisse die Ereignisbindung mit Namenskonvention (AutoEventWireup) und für Steuerelementereignisse die On-Ereignisattribute im XML-Tag. Ereignisbindung mit Namenskonvention (AutoEventWireup) AutoEventWireup stellt die Ereignisbindung über den Namen der Ereignisbehandlungsroutine her. Dabei werden alle Ereignisbehandlungsroutinen ausgeführt, deren Name der Konvention OBJEKTVARIABLE_EREIGNISNAME(PASSENDE_PARAMETERLISTE) entspricht. Die folgende Ereignisbehandlungsroutine behandelt das Ereignis Load() in der Page-Klasse: Sub Page_Load(sender as Object, e as EventArgs)... Diese automatische Ereignisbindung ist in ASP.NET automatisch aktiviert. Jede mit VWD in C# erstellte Seite enthält aber auch noch mal explizit ein AutoEventWireup="true" in der @Page-Direktive, obwohl dies eigentlich nicht notwendig wäre. Mit AutoEventWireup="false" kann die automatische Bindungsfunktion deaktiviert werden. Dies ist die Standardeinstellung für in Visual Basic erstellte Seiten. WICHTIG Die Ereignisbindung mit AutoEventWireup funktioniert nur für die Seitenereignisse der Page-Klasse, nicht für die einzelnen Steuerelementereignisse. On-Ereignisattribute Jede Steuerelement-Klasse (sowohl für HTML-Serversteuerelemente als auch für Webserversteuerelemente) bietet zu jedem Ereignis auch ein passendes On-Attribut, dem der Name einer Routine zugewiesen werden kann, die das Ereignis behandelt. VWD erstellt automatisch ein On-Ereignisattribut und die zugehörige Ereignisbehandlungsroutine im Code, wenn der Entwickler einen Doppelklick auf ein Steuerelement im Designer durchführt. XML <asp:textbox id="textbox1" runat="server" OnTextChanged="VeraenderungIstGut"> </asp:textbox> Programmcode Sub VeraenderungIstGut(ByVal sender as _ System.Object, _ ByVal e as EventArgs)

64 Kapitel 4: Das Web Forms-Programmiermodell XML Programmcode... ACHTUNG Ein»beliebtes«Problem: Sie erhalten einen Fehler der Form ' ' does not contain a definition for ' ', wenn Sie eine Ereignisbehandlungsroutine im Code löschen, ohne das entsprechende On-Ereignisbindungsattribut in der.aspx-seite zu entfernen. Auch im VWD müssen Sie das Ereignisbindungsattribut in der.aspx-seite manuell entfernen, nachdem Sie die Ereignisbehandlungsroutine entfernt haben. WICHTIG Die mit einem On-Attribut gebundene Ereignisbehandlungsroutine kann wahlweise in der ASPX-Seite oder in der Hintergrundcodedatei liegen. Wenn sie sich sowohl in der ASPX-Seite als auch in der Hintergrundcodedatei befindet, wird nur die Routine in der ASPX-Seite ausgeführt. Programmgesteuerte Ereignisbindung Bei der programmgesteuerten Ereignisbindung wird durch Programmcode die Verbindung zwischen Ereignis und Ereignisbehandlungsroutine hergestellt. In Visual Basic steht dafür das Handles-Schlüsselwort zur Verfügung, in C# der += Operator. Sub xy() Handles OBJEKTNAME.EREIGNISNAME Handles legt in der Hintergrundcodedatei fest, für welches Steuerelementereignis diese Routine die Ereignisbehandlung übernimmt. Dies hat zwei Vorteile gegenüber der Bindung im HTML-Code durch ein On-Attribut: Der Name der Ereignisbehandlungsroutine muss dem Ersteller der ASPX-Datei (z. B. einem Webdesigner) nicht bekannt sein. Es können beliebig viele Ereignisbehandlungsroutinen für jedes Ereignis definiert werden, da Handles mehrfach für das gleiche Ereignis vorkommen darf. Im Hintergrundcodemodell ist aber auch noch die Bindung über die on-attribute möglich. Wenn diese Form gewählt wird, ist zu beachten, dass die Ereignisbehandlungsroutine für die abgeleitete Klasse zugänglich sein muss. Erlaubt sind also die Modifizierer Public und Protected, nicht aber Private. XML <asp:button id="b_ok" runat="server" Text="OK"> </asp:button> Programmcode Private Sub B_OK_Click _ (ByVal sender As System.Object, _ ByVal e As System.EventArgs) _ Handles B_OK.Click Tabelle 4.5 Alternative Ereignisbindung im Hintergrundcodemodell ACHTUNG Im.NET Framework kann eine beliebige Anzahl von Ereignisbehandlungsroutinen an ein Ereignis gebunden werden. Wenn Sie <asp:button ID="Button1" runat="server" Onclick="Button1_Click" Text="Button" /> und gleichzeitig

Ereignismodell 65 Protected Sub Button1_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles Button1.Click definieren, wird die Ereignisbehandlungsroutine zweimal gebunden und bei jedem Klick auf die Schaltfläche daher auch zweimal ausgeführt. Dies ist in der Regel nicht beabsichtigt und führt zu schwer erkennbaren Seiteneffekten! Sinn machen kann dies nur, wenn für ein Ereignis sowohl in der Hintergrundcodedatei als auch in der ASPX-Seite eine Ereignisbehandlung mit unterschiedlichem Namen definiert ist. Ereignisparameter Ereignisse und Ereignisbehandlungsroutinen sind im.net Framework standardisiert. Auch die ASP.NET- Serversteuerelemente folgen diesem Standard. Demnach übergeben alle Ereignisse zwei Argumente: Auslösendes Objekt (Parametertyp System.Object): ein beliebiges Objekt, welches das Ereignis auslöst Ereignisparameter: ein Objekt vom Typ System.EventArgs, welches ereignisspezifische Informationen enthält Beispiel Sub B_Eintragen_Click(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Einige Steuerelemente übergeben eine Spezialisierung des zweiten Arguments System.EventArgs. So liefert das Webserversteuerelement ImageButton ein Objekt des Typs System.Web.UI.ImageClickEventArgs, das zusätzlich die Koordinaten des Mauszeigers zum Zeitpunkt des Klicks enthält. Um auf ein Ereignis reagieren zu können, muss diese Nachricht in einen Methodenaufruf umgewandelt werden. Dieser Mechanismus wird durch eine Ereignisbehandlungsroutine (engl. event handler) bereitgestellt, in der über das Handles-Schlüsselwort angegeben wird, von welcher Art das zu verarbeitende Ereignis ist. Wie aus dem obigen Beispiel in der Hintergrundcodeklassendatei ersichtlich wird, generiert der Web Form-Designer in Visual Studio automatisch entsprechenden Code für die Ereignisbehandlungsroutinen. HINWEIS Im.NET Framework kann es zu einem Ereignis beliebig viele Ereignisbehandlungsroutinen geben. Im Ereignisfall werden alle gebundenen Ereignisbehandlungsroutinen aufgerufen. Automatischer Postback (AutoPostBack) HTML-Steuerelemente, die normalerweise keinen Postback auslösen, z. B. Auswahlfelder, können durch wenige Zeilen JavaScript dazu gebracht werden, einen Postback auszulösen, damit das Ereignis sofort und nicht erst nach dem nächsten Klick auf eine Schaltfläche verarbeitet werden kann. ASP.NET generiert auf Wunsch automatisch das notwendige Clientskript. Vom Entwickler kann über das Serversteuerelementattribut AutoPostBack definiert werden, ob eine Zustandsänderung in einem Eingabesteuerelement zum sofortigen Postback führt: <asp:dropdownlist ID="C_AnzahlMitreisende" runat="server" AutoPostBack="True"> <asp:listitem Value="1">Eins</asp:ListItem>

66 Kapitel 4: Das Web Forms-Programmiermodell <asp:listitem Value="2">Zwei</asp:ListItem> </asp:dropdownlist> Listing 4.7 Verwendung des AutoPostBack-Attributs für ein Auswahlfeld Da ein Postback in HTML nur für Submit-Schaltflächen, nicht aber für alle anderen Steuerelemente vorgesehen ist, muss ASP.NET ein Stück JavaScript-Code in die Seite einfügen, welcher das Formular zum Postback zwingt: <!-- var theform = document.forms['aspnetform']; if (!theform) { theform = document.aspnetform; } function dopostback(eventtarget, eventargument) { if (!theform.onsubmit (theform.onsubmit()!= false)) { theform. EVENTTARGET.value = eventtarget; theform. EVENTARGUMENT.value = eventargument; theform.submit(); } } // --> Listing 4.8 JavaScript-Clientskriptcode für AutoPostBack in ASP.NET2.0 Zusätzlich muss der für das Serversteuerelement generierte HTML-Tag einen Aufruf der obigen Routine enthalten. Im Fall des DropDownList-Steuerelements entspricht ein onchange() in DHTML einem SelectedIndexChanged() in ASP.NET: <select name="ctl00$p_maincontent$c_anzahlmitreisende" onchange="javascript:settimeout(' dopostback(\'ctl00$p_maincontent$c_anzahlmitreisende\',\'\')', 0)" id="ctl00_p_maincontent_c_anzahlmitreisende" style="color:black;"> Listing 4.9 Umsetzung eines Auswahlfelds mit aktiviertem AutoPostBack in HTML WICHTIG Wenn im Browser JavaScript deaktiviert ist, funktioniert ein solcher manueller Postback nicht. Sie sollten also keine Web Forms erzeugen, die nur mit einem manuellen Postback verlassen werden können. Postbackabhängiger Code ASP.NET stellt einen Mechanismus zur Verfügung, der über eine programmseitige Prüfung gestattet, ob eine Webseite zum ersten Mal geladen oder ob die Seite im Rahmen eines Postbacks erneut aufgerufen wird. Hierzu stellt die Seitenklasse das Nur-Lesen-Attribut IsPostBack zur Verfügung, das zur Laufzeit abgefragt werden kann. Entsprechend lassen sich ressourcenintensive Operationen wie z. B. Datenbankinitialisierungen abhängig von diesem Attribut ausführen: Sub Page_Load(ByVal Sender as Object, ByVal e as EventArgs) if not Page.IsPostBack then --- ressourcenintensive Operationen werden hier platziert End If

Ereignismodell 67 Listing 4.10 Verwendung von IsPostBack() HINWEIS Der Seitenzustandsmechanismus in ASP.NET (Viewstate, siehe Kapitel 12»Zustandsverwaltung«) sorgt dafür, dass die Zustände der Steuerelemente nach einem Postback nicht verloren gehen und ein erneutes Setzen der Zustände bei einem Postback nicht notwendig ist. Ereignishierarchien und Ereignisweitergabe ASP.NET bietet die Möglichkeit, eine Webanwendung aus komplexen Steuerelementen zu bauen. Hierzu zählen Calendar, GridView, DataList und Repeater, aber auch benutzerdefinierte Steuerelemente, die aus anderen Steuerelementen zusammengesetzt werden können. Beispielsweise könnte eine Tabelle mit Datensätzen aus einer Datenbank in jeder Zeile eine Schaltfläche enthalten, mit dem der jeweilige Datensatz editiert werden kann. In diesem Fall erzeugt nicht jede Schaltfläche einzeln ein Klickereignis. Vielmehr werden für eingebettete Steuerelemente die Ereignisse an das verantwortliche Vaterelement weitergeleitet. Das Vatersteuerelement erzeugt seinerseits ein generisches ItemCommand()-Ereignis, in dem entsprechende Parameter enthalten sind, die es erlauben, das Kindelement zu ermitteln. Es muss also nicht für jedes Kindsteuerelement eine eigene Ereignisbehandlungsroutine geschrieben werden. Beispiele für die Ereignisbindung Dieser Abschnitt enthält mehrere Beispiele für die Ereignisbindung in ASP.NET. Beispiel 1 Das folgende Beispiel zeigt die Implementierung von Ereignisbehandlungsroutinen für die verschiedenen Arten von Ereignissen. Das Beispiel demonstriert, wie auf die verschiedenen systembedingten und benutzerausgelösten Ereignisse mittels entsprechender Ereignisbehandlungsroutinen reagiert werden kann. Dadurch, dass hinter den jeweiligen Ereignisbehandlungsroutinen mithilfe des Schlüsselworts Handles die Art des zu verarbeitenden Ereignisses angegeben wurde, kann der Name der jeweiligen Ereignisbehandlungsroutine frei gewählt werden: Public Class Ereignisse Inherits System.Web.UI.Page Private Sub SeitenLadeEreignis(ByVal sender As System.Object, ByVal e As EventArgs) _ Handles MyBase.Load Response.Write("<h1>Ereignisbehandlung in ASP.NET</h1>") Response.Write("Seite wird geladen...<br>") If IsPostBack Then Response.Write("Seite wurde zurückgeschickt...<br>") End If Private Sub EreignisnameSpieltKeineRolle(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles Button1.Click Response.Write("Button wurde angeklickt.<br>")

68 Kapitel 4: Das Web Forms-Programmiermodell Private Sub TextBoxHatAnderenInhalt(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles TextBox1.TextChanged Response.Write("Inhalt der Textbox hat sich verändert...<br>") End Class Listing 4.11 Ereignisse.aspx.vb: Hintergrundcodeklassendatei des Beispiels Es folgt das Listing der zugehörigen.aspx-seite: <%@ Page Language="vb" AutoEventWireup="false" CodeFile="Ereignisse.aspx.vb" Inherits="Kapitel3.Ereignisse"%> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML> <HEAD> <title>ereignisse</title> </HEAD> <body> <form id="form1" method="post" runat="server"> <P><asp:textbox id="textbox1" runat="server" Width="219px"></asp:textbox><asp:button id="button1" runat="server" Text="Button"></asp:button></P> </form> </body> </HTML> Listing 4.12 Ereignisse.aspx: Web Form-Quellcode des Beispiels Abbildung 4.8 Ausgabe aus den verschiedenen Ereignisbehandlungsroutinen Beispiel 2 Das folgende Beispiel zeigt die Verwendung des AutoEventWireup-Mechanismus und der On???-Bindung des obigen Beispiels:

Ereignismodell 69 <%@ Page Language="vb" AutoEventWireup="true"%> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML> <HEAD> <title>ereignisse_inline</title> <script runat="server"> sub Page_Load(ByVal sender as System.Object, ByVal e as EventArgs) Response.Write("<h1>Ereignisbehandlung in ASP.NET</h1>") Response.Write("<h2>Inline Version</h2>") if ispostback then Response.Write("Seite wurde zurückgeschickt...<br>") end if end sub sub VeraenderungIstGut(ByVal sender as System.Object, ByVal e as EventArgs) Response.Write ("Text wurde verändert...<br>") end sub sub Button1Klick(ByVal sender as System.Object, ByVal e as EventArgs) Response.Write ("Button wurde angeklickt...<br>") end sub </script> </HEAD> <body> <form id="form1" method="post" runat="server"> <asp:textbox id="textbox1" runat="server" OnTextChanged="VeraenderungIstGut"></asp:TextBox> <asp:button id="button1" runat="server" Text="Button" OnClick="Button1Klick"></asp:Button> </form> </body> </HTML> Listing 4.13 Beispiel1.aspx Beispiel 3 Das folgende Beispiel demonstriert alle drei Möglichkeiten der Ereignisbindung anhand einer Webseite, die nach dem Hintergrundcodemodell entwickelt wurde. In diesem Beispiel wird zur übersichtlichen Ausgabe ein ListBox-Steuerelement verwendet, das erst später in Kapitel 8»Webserversteuerelemente«besprochen wird. <%@ Page Language="vb" AutoEventWireup="true" CodeFile="Ereignisbindung.aspx.vb" Inherits="Ereignisbindung" debug="true" trace="true"%> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML> <body> <form id="form1" method="post" runat="server"> <P><FONT size="5">test-seite über ASP.NET-Ereignisbindung</FONT></P> <P><FONT size="4"> <asp:button id="schaltflaeche" runat="server" Text="Klick mich!" OnClick="KlickEreignisbehandlung"></asp:Button></FONT></P> <P> <asp:listbox id="ausgabe" runat="server" Width="647px" Height="325px" EnableViewState="False"></asp:ListBox></P> </form> <script runat="server"> Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs)

70 Kapitel 4: Das Web Forms-Programmiermodell Ausgabe.Items.Add("Page_Load in ASPX (AutoEventWireUp)") Private Sub Page_Load2(ByVal sender As System.Object, ByVal e As System.EventArgs) _ Handles MyBase.Load Ausgabe.Items.Add("Page_Load2 in ASPX (Handles)") Private Sub Schaltflaeche_Click(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Ausgabe.Items.Add("Schaltflaeche_Click in ASPX (AutoEventWireUp)") Private Sub Schaltflaeche_Click2(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles Schaltflaeche.Click Ausgabe.Items.Add("Schaltflaeche_Click2 in ASPX (Handles)") Private Sub KlickEreignisbehandlung(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Ausgabe.Items.Add("KlickEreignisbehandlung in ASPX (OnClick=)") Public Sub KlickEreignisbehandlung2(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Ausgabe.Items.Add("KlickEreignisbehandlung2 in CB (AddHandler)") Private Sub Schaltflaeche_Init(ByVal sender As Object, ByVal e As System.EventArgs) _ Handles Schaltflaeche.Init AddHandler Schaltflaeche.Click, AddressOf KlickEreignisbehandlung2 </script> </body> </HTML> Das nächste Beispiel enthält die Hintergrundcodedatei, in der genau die gleichen Ereignisbehandlungsroutinen nochmals definiert werden: Public Class Ereignisbindung Inherits System.Web.UI.Page Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Ausgabe.Items.Add("Page_Load in CB (AutoEventWireUp)") Private Sub Page_Load2(ByVal sender As System.Object, ByVal e As System.EventArgs) _ Handles MyBase.Load Ausgabe.Items.Add("Page_Load2 in CB (Handles)") Private Sub Schaltflaeche_Click(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles Schaltflaeche.Click Ausgabe.Items.Add("Schaltflaeche_Click in CB (AutoEventWireUp)") Private Sub Schaltflaeche_Click2(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles Schaltflaeche.Click Ausgabe.Items.Add("Schaltflaeche_Click2 in CB (Handles)")

Seitenübergänge 71 Public Sub KlickEreignisbehandlung(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Ausgabe.Items.Add("KlickEreignisbehandlung in CB (OnClick)") Public Sub KlickEreignisbehandlung2(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Ausgabe.Items.Add("KlickEreignisbehandlung2 in CB (AddHandler)") Private Sub Schaltflaeche_Init(ByVal sender As Object, ByVal e As System.EventArgs) _ Handles Schaltflaeche.Init AddHandler Schaltflaeche.Click, AddressOf KlickEreignisbehandlung2 End Class Seitenübergänge Theoretisch ist es möglich, eine komplette serverseitige Webanwendung in nur einer Codedatei zu erzeugen, wobei der Programmcode immer wieder andere HTML-Dokumente generiert (dies zeigt die linke stilisierte Seite in Abbildung 4.9). Daraus würde eine Ein-Datei-Anwendung (Single Page Application SPA) entstehen. In der Praxis würde diese eine Datei jedoch in vielen Fällen extrem lang und aufgrund der notwendigen Fallunterscheidungen unübersichtlich werden. Man teilt daher die Anwendung besser auf mehrere Dateien auf. Dafür benötigt man dann aber die Möglichkeit, aus einer Datei eine andere aufzurufen und dabei Daten zu übergeben. Webanwendungen bestehen in der Regel aus einer Abfolge von mehreren Webseiten. Zwischen den Seiten erfolgen Seitenübergänge. HINWEIS ASP.NET bietet sowohl eine Unterstützung für das Ein-Seiten-Modell (durch das MultiView-Steuerelement) als auch die Seitenübergänge (durch verschiedene Techniken, die im Folgenden besprochen werden). Beide Ansätze können in ASP.NET beliebig vermischt werden.

72 Kapitel 4: Das Web Forms-Programmiermodell eine Code-Datei erzeugt verschiedene HTML-Dokumente pro HTML-Dokument eine Code-Datei Code Code Code Code Webserver Seitenübergang Seitenübergang HTML HTML HTML HTML HTML Webbrowser (C) Holger@Schwichtenberg.de 2002 Abbildung 4.9 Alternative Programmierweisen eines Seitenübergangs, die aber auch miteinander kombiniert werden können Grundsätzlich kann man einen Seitenübergang danach einteilen, ob er vom Client oder vom Server initiiert wird: Ein clientseitiger Seitenübergang (Client Redirect) basiert auf einer Aktion des Anwenders (also einem Klick auf einen Link oder eine Schaltfläche) oder auf einer im HTML-Code definierten Weiterleitung per Meta-Tags. In beiden Fällen zeigt der Browser danach eine neue Seite an. Bei einem serverseitigen Seitenübergang (Server Redirect) initiiert der Code auf dem Server, dass nun eine andere als die vom Browser angefragte Seite angezeigt werden soll. Eine Webserverprogrammierumgebung hat dazu entweder die Möglichkeit, intern die Kontrolle an eine andere Seite im gleichen Web zu übergeben oder aber den Browser durch einen speziellen HTTP-Status-Code (302 Object Moved) anzuweisen, eine andere Seite anzufragen. Bei klassischen ASP-Anwendungen führten Links oder Submit-Schaltflächen den Benutzer oft sofort zu einer anderen HTML-Seite. Zusätzlich konnten serverseitige Seitenübergänge mit Response.Redirect() oder Server.Transfer() initiiert werden.

Seitenübergänge 73 vom Client initierter Seitenübergang vom Server initierter Seitenübergang GET POST Seite1.asp Seite2.asp Seite1.asp Seite2.asp Webserver ASP-Verarbeitung GET ASP-Verarbeitung ASP- Verarbeitung Server.Transfer ("Seite2.aspx") ASP-Verarbeitung Response.Redirect "Seite2.asp" GET GET HTTP200 HTTP200 HTTP302 Seite2.asp HTTP200 Webbrowser Meta-Tag 0000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000 Link Browser stellt leeres Dokument nicht dar, sondern fragt direkt nach der übermittelten Seite erneut an. (C) Holger@Schwichtenberg.de 2002 Abbildung 4.10 Seitenübergänge im klassischen ASP Das serverseitige Programmiermodell in ASP.NET erfordert ein neues Ablaufmodell bei Seitenübergängen. ASP.NET geht in seinem Anwendungsmodell etwas weg von clientbasierten Seitenübergängen hin zu einem Modell, in dem ASPX-Seiten ihre Angelegenheiten primär selbst regeln. Ein Seitenübergang von einer Webseite zur nächsten erfolgt in ASP.NET so, dass zunächst die aktuelle Seite erneut aufgerufen wird, damit die dort hinterlegten Ereignisbehandlungsroutinen ausgeführt werden können. Erst nachdem diese abgearbeitet wurden, erfolgt der Aufruf der nächsten Seite. Dies bezeichnet man in ASP.NET als Postback-Architektur. In ASP.NET 1.x war für die Ereignisfunktionalität im Web Forms-Programmiermodell grundsätzlich immer erforderlich, dass sich eine Seite zunächst selbst aufruft, um ihre Ereignisbehandlungsroutinen für die serverseitigen Steuerelemente auszuführen. In Web Forms gibt es daher in serverseitigen <form>-tags kein Action-Attribut, mit dem man normalerweise in HTML die Zielseite bestimmt. Die Angabe des Action- Attributs hätte keine Wirkung: Wenn ein <form>-tag über das Attribut runat=server verfügt, wird ein eventuell vorhandenes Action-Attribut im <form>-tag ignoriert. Auch bei einigen Formen von Links wird (unter Einsatz von Clientskripts) zunächst die aktuelle Seite erneut aufgerufen. Erst dann darf der Seitenübergang serverseitig initiiert werden. Dazu stehen Response.Redirect() und Server.Transfer() zur Verfügung. In ASP.NET erlaubt seit Version 2.0 nun eine zusätzliche Option so genannte Cross-Page-Postbacks, bei denen der Client eine andere Seite beim Absenden einer Seite aufrufen darf und die Zielseite dennoch einige der Möglichkeiten des Web Forms-Programmiermodells nutzen kann.