Kapitel 4 Das Webform- Programmiermodell

Transkript

1 Kapitel 4 Das Webform- Programmiermodell ASP.NET beinhaltet ein neues Programmiermodell für Webseiten. Dieses Modell wird als Webform- Programmiermodell oder ASP.NET Page Framework bezeichnet. Ein Webform ist eine.aspx-seite, die neben konventionellem HTML-Code auch sogenannte Serversteuerelemente (in XML-Form) beinhaltet. WICHTIG Ein Webform enthält nicht notwendigerweise ein Eingabeformular. Der Begriff Webform bezeichnet in ASP.NET allgemein eine Webseite, die mit serverseitigem Code ausgestattet ist. Die nachstehende Abbildung zeigt eine grobe Sicht auf das ASP.NET-Programmiermodell: Der Webserver 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. Das unterscheidet 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 (Rendering). Dies wird in den folgenden Kapiteln 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.1 Client-Server-Architektur unter Einsatz von ASP.NET

2 24 Kapitel 4 Das Webform-Programmiermodell ASP.NET und der Client ASP.NET ist primär eine serverseitige Web-Technologie, d. h., 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. 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. In Zukunft wird ASP.NET noch mehr Unterstützung für JavaScript bieten. Diese Ausnahme ändert aber nichts daran, dass man nicht erwarten darf, dass ASP.NET den Client komplett selbst steuern kann. Durch die ASP.NET AJAX-Erweiterungen wird der clientseitige Anteil von ASP.NET stark vergrößert. Abstraktion durch Serversteuerelemente (Adaptive Rendering) Das Webforms-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 bezeichnet. Serversteuerelemente werden nicht 1:1 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 WML oder chtml etc. Aus jedem Serversteuerelement werden ein oder mehrere Tags generiert. Der Webbrowser erhält nur ihm bekannte Tags (und ggf. clientseitigen Skriptcode), weil alle Serversteuerelemente bereits auf der Serverseite in browserspezifische Tags umgesetzt werden. Dieser Vorgang wird Adaptive Rendering genannt. Beispielsweise wird aus dem Serversteuerelement <asp:textbox> bei der Umwandlung das HTML-Tag <input type=text>. Konventionelle HTML-Tags werden wie bisher ohne Verarbeitung auf dem Server an den Client übertragen.

3 Objektorientierung 25 Kompatibilität zu Windows Forms Auch wenn sich die Programmiermodelle von Windows Forms (also Windows-Anwendungen) und Webforms (Webseiten) sehr ähnlich geworden sind, so sind sie doch leider überhaupt nicht zueinander kompatibel. Die Hoffnung vieler Entwickler, in Zukunft in der Windows-Welt gestaltete Benutzeroberflächen einfach in das Web übernehmen zu können, hat sich auch mit dem.net Framework 2.0, 3.0 und 3.5 nicht erfüllt. In Windows Forms wird die gesamte Benutzeroberfläche durch Programmbefehle erzeugt. Der Visual Studio- Designer für Windows Forms generiert durch die Aktionen des Benutzers (Drag&Drop, Änderungen im Eigenschaftsfenster etc.) Programmcode in der gewählten Programmiersprache. Bei Webforms wird die Benutzerschnittstelle dagegen durch eine Mischung aus klassischem HTML-Code und neuen Tags (Serversteuerelementen) beschrieben und in der Regel in einer von dem Programmcode getrennten Datei abgelegt. Die Steuerelemente in Webforms und Windows Forms sind (aus berechtigtem Grund) verschieden. Es gibt aber auch keinen Assistenten, der die mächtigeren Windows Forms-Steuerelemente in Webforms- Steuerelemente umwandelt. Zwar wäre sicherlich nicht alles automatisch konvertierbar, jedoch hat man leider die Chance verpasst, eine Architektur und zugehörige Werkzeuge zu schaffen, welche die Übernahme von Anwendungen vom Windows Desktop in das Web erleichtern. Auch in dem Windows Forms-Nachfolger Windows Presentation Foundation (WPF) (siehe Kapitel»Windows Presentation Foundation (WPF)«) gibt es leider keine Austauschbarkeit zwischen Desktop- und Web-Steuerelementen. Objektorientierung Das Webforms-Programmiermodell in ASP.NET ist objektorientiert und ereignisbasiert (ähnlich der Entwicklung von Desktop-Anwendungen mit Visual Basic 6.0 und Windows Forms in.net). Bei den Serversteuerelementen sind zwei Darstellungsformen zu unterscheiden: In der.aspx-seite sind Serversteuerelemente (Server Controls) repräsentiert durch Tags (Serversteuerelement-Tag oder Server Control Tag) mit dem Attribut runat="server" und einem Präfix (im Standard 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 Webform selbst ist eine von der Klasse System.Web.UI.Page abgeleitete Klasse. Sie wird auch als Seitenklasse bezeichnet. HINWEIS Um die Herausforderungen des parallelen Zugriffs durch zahlreiche Benutzer muss sich der Entwickler in ASP.NET (anders als beispielsweise in Java Servlets) keine Gedanken machen, da jeder einzelne Aufruf eine eigene Instanz der von Page abgeleiteten Seitenklasse erhält.

4 26 Kapitel 4 Das Webform-Programmiermodell Abbildung 4.2 Abstraktion durch Serversteuerelemente 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. Deklaration in der.aspx-seite (Serversteuerelement-Tags) <asp:textbox id="vorname" runat="server">kein Name eingetragen </asp:textbox> Verwendung im Programmcode (Serversteuerelementobjekt) Vorname.Text = "Holger" Tabelle 4.1 Verwendung von Serversteuerelementen HINWEIS Der objektorientierte programmatische 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. Microsoft macht dazu die Werbeaussage, dass in ASP.NET gegenüber ASP zwischen 40 % und 70 % weniger Programmcode geschrieben werden muss. Ab ASP.NET 2.0 soll der Aufwand nochmals um 70 % reduziert worden sein. Beispiel Anhand eines einfachen Beispiels kann der Unterschied in der Programmierung zwischen dem klassischen»hinausschreiben«von HTML und der objektorientierten Programmierung in ASP.NET gezeigt werden. Die Anwendung erhöht den Wert in einem Eingabefeld bei jedem Roundtrip um eins. Wenn die Zahl gerade ist, bekommt das Textfeld einen gelben, sonst einen grünen Hintergrund.

5 Objektorientierung 27 Abbildung 4.3 Erhöhen eines Zählers in einem Eingabefeld <!--- 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.1 Lösung in ASP In der Gegenüberstellung dazu folgt nun die elegantere Lösung in ASP.NET. <!--- 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 End Sub </script> Listing 4.2 Lösung in ASP.NET 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 statisches HTML. Der Einsatz sollte daher wohl überlegt sein.

6 28 Kapitel 4 Das Webform-Programmiermodell Steuerelement-Hierarchie (Objektbaum) Genau wie bei Windows Forms bilden die Steuerelemente einer Webseite 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 sind Container für andere Steuerelemente. Diese Container-Steuerelemente besitzen wiederum untergeordnete Steuerelemente in ihrer Controls- Menge, sodass ein Objektbaum entsteht. Ereignisbehandlung Die Benutzerschnittstellensteuerung liegt bei ASP.NET in serverseitigen Ereignisbehandlungsroutinen für die Serversteuerelementereignisse. Es gibt zwei Arten von Ereignissen: Ereignisse, die im Rahmen der verschiedenen Verarbeitungsschritte einer ASPX-Datei auf dem Server ausgelöst werden (z. B. Page_Load(), TextBox1_PreRender()) Ereignisse, die Aktionen und Zustandsänderungen (z. B. neuen Werten) auf dem Client entsprechen (beispielsweise Button1_Click(), Textbox1_TextChanged()) Letztere Ereignisse sind nur Pseudo-Ereignisse, weil es kein echtes Ereignissystem zwischen Client und Server gibt. Eine Datenübertragung vom Browser an den Server findet im Rahmen einer erneuten HTTP- Anfrage (Rundgang / 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 Eingabefelds. Das ASP.NET Page Framework analysiert die HTTP-Anfrage und erzeugt daraus (zeitverzögert) Ereignisse auf dem Server für Änderungen, die vorher im Client erfolgt sind. Zum Webforms-Programmiermodell gehört es, dass alle Roundtrips auf einem HTTP-POST basieren man spricht dabei von einem Postback. Durch clientseitigen Javascript-Code wird erreicht, dass auch ein Klick auf einen Hyperlink oder die Wertänderung in einem Eingabefeld einen Postback anstoßen können. Ob ein Serversteuerelement bei einem Klick oder einer Wertänderung einen Postback auslöst, ist konfigurierbar (Attribut AutoPostBack). Für Steuerelemente wie Texteingabefelder, die in HTML normalerweise keinen Postback auslösen, wird dieser durch ein kleines JavaScript hervorgerufen ( dopostback()). Die folgende Abbildung 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 Roundtrip. 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, wenn 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 (DHTML) würden in diesem Fall zwei Änderungsereignisse auf dem Client ausgelöst.

7 Ereignisbehandlung 29 Browser Webserver (C) 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.4 Ereignisbasierte Programmierung Die Bindung der Ereignisbehandlungsroutinen an die Steuerelemente erfolgt in ASP.NET durch ein Attribut im Steuerelement-Tag (z. B. OnClick="C_Absenden_Click") oder durch Namenskonventionen. Der VWD erstellt Ereignisbindungen zumeist nach dem ersten Verfahren. Das zweite Verfahren setzt voraus, dass Sie manuell AutoEventWireUp="true" in der Page-Direktive setzen. Ereignisse können an übergeordnete Serversteuerelemente weitergeleitet werden. Beispielsweise wird der Klick auf einen Link in einem DataGrid als ein Ereignis des DataGrid aufgefasst. Immer automatisch gebunden werden die Seiten- Ereignisse Page_Load(), Page_AbortTransaction(), Page_CommitTransaction(), Page_DataBinding(), Page_Disposed(), Page_Error(), Page_Init(), Page_Init Complete(), Page_Load(), Page_LoadComplete, Page_PreInit(), Page_PreLoad(), Page_PreRender(), Page_PreRenderComplete(), Page_SaveStateComplete(), Page_Unload(). ACHTUNG Ein»beliebtes«Problem: Eine Fehlermeldung der Form ' ' does not contain a definition for ' ' sehen Sie, wenn Sie eine Ereignisbehandlungsroutine im Code löschen, ohne das entsprechende 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 gelöscht haben.

8 30 Kapitel 4 Das Webform-Programmiermodell Seitenübergänge Damit die serverseitigen Ereignisse abgearbeitet werden können, wird im Webforms-Programmiermodell bei einem Postback immer wieder die gleiche Seite selbst aufgerufen. In Webforms gibt es daher in serverseitigen <Form>-Tags kein Action-Attribut. Das Action-Attribut anzugeben hätte keine Wirkung. Auch bei einigen Formen von Hyperlinks wird (unter Einsatz von Client-Skripten) zunächst die aktuelle Seite erneut aufgerufen. Daher spricht man bei ASP.NET-Webforms auch von einer Postback-Architektur. GET Seite1.aspx Code-Block/-Datei Seite2.aspx Code-Block/-Datei Webserver POST POST Ereignis- Verarbeitung Server.Transfer ("Seite2.aspx") Response.Redirect ("Seite2.aspx") GET Ereignis-Verarbeitung HTTP200 HTTP302 Seite2.asp HTTP200 Webbrowser (C) Holger@Schwichtenberg.de 2002 Link Browser stellt leeres Dokument nicht dar, sondern fragt direkt nach der übermittelten Seite erneut an. Abbildung 4.5 Seitenübergänge im Webforms-Programmiermodell Ein tatsächlicher Seitenübergang muss im Programmcode explizit ausgedrückt werden. Dazu gibt es zwei Optionen: Serverseitiger Seitenübergang durch Übergabe der Programmkontrolle an die nächste.aspx-seite: Server.Transfer() Clientseitiger Seitenübergang durch Umleitung des Clients (Senden des HTTP-Status-Codes 302 an den Client): Response.Redirect() Für eine ausführliche Diskussion der Unterschiede sei auf [DOTNET04] verwiesen.

9 Trennung von Layout und Programmcode 31 Cross-Page-Postbacks Während in ASP.NET 1.x ein Postback immer auf dieselbe Seite erfolgt, unterstützt ASP.NET seit Version 2.0 zusätzlich sogenannte Cross-Page-Postbacks. Jedes Schaltflächen-Steuerelement (<asp:button>, <asp:imagebutton> und <asp:linkbutton>) darf im Attribut PostBackUrl auf eine beliebige Seite verweisen. <asp:button ID= C_Absenden Runat= server Text= Absenden PostBackUrl= ~/Global/FormularEinsenden.aspx /> Aus der Sicht des Clients wird diese Funktion durch eine JavaScript-Funktion (WebForm_DoPostBackWithOptions()) realisiert. Die Zielseite kann über Page.PreviousPage auf die Daten aus der Ursprungsseite zugreifen. Trennung von Layout und Programmcode Zu den Grundkonzepten von ASP.NET gehört die Möglichkeit, den HTML-Code (das Layout) und den Programmcode in zwei verschiedene Dateien aufzuteilen (Hintergrundcodemodell, engl. Code-Behind-Model). Die aus dem klassischen ASP übernommene Option, HTML-Code und Programmcode in einer Datei zu vermischen, wird hingegen als Eindateimodell (alias: Single-File-Model oder Inline-Code) bezeichnet. Visual Studio.NET 2002 und 2003 erzeugten jedes Webform automatisch nach dem Hintergrundcodemodell, während der kostenlose ASP.NET-Editor Microsoft Web Matrix nur das Eindateimodell unterstützte. Der VWD bietet nun beide Modelle an, wobei das Eindateimodell die Grundeinstellung ist. Möchte man ein Webform nach dem Hintergrundcodekonzept erzeugen, ist im Dialog Neues Element hinzufügen (Add New Item) die Option Code in eigener Datei platzieren (Place code in separate file) zusätzlich anzuwählen. TIPP Die Hintergrundcodedatei zu einem ASP.NET-Webform zeigt der VWD nur an, wenn man das Symbol Show all Files im Solution Explorer aktiviert. Im Eindateimodell sind die Ereignisbehandlungsroutinen in <Script runat= Server >-Blöcken in die.aspx- Seite integriert. Im Hintergrundcodemodell implementiert die Codedatei eine Klasse. Die Codeklasse erbt von System.Web.UI.Page und bildet die Oberklasse für die aus der.aspx-datei zu erzeugende Klasse. HINWEIS Die ursprünglich für ASP.NET 2.0 geplante und bis Beta 1 vorhandene Verbindung der beiden Klassen als partielle Klassen (sogenannte Code-Besides-Klassen) ist leider trotz der Eleganz der Lösung verworfen worden, weil die Migration von ASP.NET 1.x als zu kompliziert betrachtet wurde. Die Hintergrundcodeklasse ist dennoch als partielle Klasse zu kennzeichnen, weil das aktuelle Modell eine Synthese aus Code-Behind- und Code-Besides-Modell ist. Erläuterungen dazu finden Sie im nächsten Abschnitt. Verbindendes Element zwischen den beiden Klassen ist die Page-Direktive in der.aspx-datei. Hier deutet codefile auf den Dateinamen der Codeklasse und inherits auf den Namen der in dieser Datei implementierten Klasse. <%@ Page Language="VB" codefile="formulareinsenden.aspx.vb" inherits="formulareinsenden"%> TIPP Man kann die Hintergrundcodeklasse von einer anderen Klasse als System.Web.UI.Page erben lassen. In diesem Fall muss man aber auch der.aspx-seite die neue Basisklasse mitteilen mit dem Attribut CodeFileBaseClass in Direktive.

10 32 Kapitel 4 Das Webform-Programmiermodell WICHTIG Beim Umbenennen einer.aspx-datei ändert der VWD automatisch auch den Namen der Codeklasse und des codefile-attributs, nicht jedoch den Klassennamen und das inherits-attribut. ASP ASP.NET ASP-Datei ASPX-Datei Code-Behind-Datei <HTML-Element> <%Render Block%> <HTML-Fragment> <%Display Block%> <HTML-Fragment> <HTML-Element> <Webcontrol-Element> Page_Load() Ereignisbehandlungsroutine <SCRIPT runat=server> sub Unterroutine1() <HTML-Element> <HTML-Element> Unterroutine1() Abbildung 4.6 Trennung von Layout und Code in ASP.NET Übersetzungsvorgang und Verbreitung Während der Programmcode in klassischen ASP-Seiten interpretiert wird, kommen in ASP.NET Compiler zum Einsatz. Grundlagen des Kompilierungsmodells Das Kompilierungsmodell ist dabei seit ASP.NET 2.0 noch etwas komplexer als in ASP.NET 1.x, weil die Anforderung entstanden ist, dass in der Hintergrundcodeklasse kein vom Designer generierter Code enthalten sein soll. In ASP.NET 1.x musste dort jedes Steuerelement, das in der.aspx-seite verwendet wurde, als Protected-Mitglied deklariert sein, damit der Programmcode in der Hintergrundcodeklasse die Mitglieder nutzen konnte. Visual Studio.NET 2002 / 2003 gelang es dabei nicht immer, die Steuerelemente und die Deklarationen konsistent zu halten. Außerdem machte das Modell das gemeinsame Arbeiten eines Layouters an der.aspx-seite und eines Entwicklers an der Hintergrundcodedatei schwierig. Ab ASP.NET 2.0 werden diese Protected-Mitglieder nun zur Übersetzungszeit aus der.aspx-seite generiert. Die.aspx-Seite wird nicht wie bisher in genau eine Klasse umgewandelt, sondern es entstehen zwei Klassen: Die erste Klasse (name_aspx) ist eine als partiell deklarierte Klasse. Sie enthält für jedes Serversteuerelement eine Protected-Mitgliederdeklaration. Diese Klasse bildet den Gegenpart zu der Klasse in der Hintergrundcodedatei (ebenfalls name_aspx), die daher auch immer als partiell deklariert sein muss. In der zweiten Klasse (name_aspx) erzeugt das ASP.NET Page Framework Quellcode für alle HTML- und Server-Tags in der.aspx-seite, d. h., der komplette Tag-Code wird in Programmcode umgesetzt. Diese Klasse erbt von der ersten Klasse und damit auch von dem in der Hintergrundcodedatei enthaltenen Gegenstück.

11 Übersetzungsvorgang und Verbreitung 33 Da die Hintergrundcodeklasse von der in der FCL implementierten Basisklasse System.Web.UI.Page erbt, erbt folglich also indirekt auch die Klasse_name_aspx von der Page-Klasse. Die Klasse name_aspx wird dann in eine DLL übersetzt und kann von dem Webserver zur Erzeugung der Ausgabe an den Client aufgerufen werden. name.aspx [Quellcode] Page Codebehind= "name.aspx.vb" Inherits="name_aspx" > Server Control Tag HTML-Block Code-Generierung name.aspx.vb [Quellcode] Partial Class name_aspx Inherits System.Web.UI.Page Unterroutine1 Unterroutine2 Unterroutine3 Code-Generierung Web-Anwendungsverzeichnis %FRAMEWORK%/ Temporary ASP.NET Files name_aspx [Quellcode] name.aspx.vb [Quellcode] Transfer Partial Class name_aspx Deklaration der Control-Objekte Partial Class name_aspx Inherits System.Web.UI.Page Unterroutine1 Unterroutine2 Unterroutine3 _name.aspx [Quellcode] Partial Class _name_aspx Inherits name_aspx In Code umgewandelter HTML-Block Erbt von Instanziierung der Control-Objekte Kompilierung (vbc.exe) TEMPNAME.dll [MSIL] Gesamter Code (C) 2005 Abbildung 4.7 Übersetzungsvorgang einer ASP.NET-Webseite

12 34 Kapitel 4 Das Webform-Programmiermodell Autokompilierung In Visual Studio.NET 2002 / 2003 wurden alle Hintergrundcodeklassen und eigenständigen Codedateien immer zur Entwicklungszeit in eine einzige.dll-datei kompiliert. Diese Funktion entfällt im VWD: Der dortige Übersetzungsvorgang hat nur die Aufgabe, die Kompilierbarkeit zur Entwicklungszeit zu prüfen. Daher ist die Entwicklungskompilierung einer Webanwendung im VWD optional. Das Standardübersetzungsmodell ab ASP.NET 2.0 ist die Kompilierung beim ersten Aufruf einer Website (Auto- Kompilierung, Ad-hoc-Kompilierung). ASP.NET 2.0 / 3.5 erzeugen pro Webseite eine Assembly beim ersten Aufruf. Alle Klassen, die nicht Hintergrundcodeklassen sind (also die Klassen im Verzeichnis /App_Code), werden in eine einzige separate Assembly kompiliert, sobald die erste Webseite in der Anwendung aufgerufen wird. Präkompilierung Das ASP.NET Page Framework 2.0 / 3.5 unterstützt die Möglichkeit, eine komplette ASP.NET-Webanwendung inklusive der.aspx-seiten zur Entwicklungszeit zu kompilieren und in diesem kompilierten Zustand auszuliefern. Die Präkompilierung erzeugt wahlweise eine DLL-Assembly für die gesamte Webanwendung oder eine DLL-Assembly für jede Webseite und eine DLL-Assembly für jede in /App_Code verwendete Programmiersprache. Außerdem entsteht eine neue Konfigurationsdatei PrecompiledApp.config. Eine weitere Option betrifft die Auslieferung der.aspx-dateien. Der Entwickler hat die Wahl: Die Webanwendung wird präkompiliert und die Inhalte der.aspx-dateien werden zusätzlich mit ausgeliefert, sodass diese auf dem Zielsystem noch geändert werden können, wodurch eine Ad-hoc- Neukompilierung der geänderten Seite angestoßen würde. In der Wortwahl von ASP.NET 2.0 / 3.5 heißt diese Option Aktualisierbare, präkompilierte Webanwendung. Die Webanwendung wird präkompiliert und die Inhalte der.aspx-dateien werden nicht an das Zielsystem übergeben. Der Empfänger kann also das Layout nicht ändern. Dies ist die beste Option zum Schutz des geistigen Eigentums und zum Schutz vor ungewollten Eingriffen der Empfänger. In der Wortwahl von ASP.NET 2.0 / 3.5 heißt diese Option Nicht aktualisierbare, präkompilierte Webanwendung. Auch die ASPX-Dateien sind noch in der Ausgabe enthalten, jedoch fehlt der eigentliche Code. Stattdessen enthalten alle Dateien nur noch den Satz:»This is a marker file generated by the precompilation tool, and should not be deleted!«. Die.aspx-Dateien dienen also dem Webserver nur als Markierungsdateien und zur Aufrechterhaltung der NTFS-Dateisystemrechte. Der VWD stellt die Präkompilierung im Menüpunkt Erstellen/Website veröffentlichen (Build/Publish Website) bereit (gilt leider nicht für Visual Web Developer Express). Im Gegensatz dazu kopiert Website/Website kopieren (Website/Copy WebSite) nur Dateien auf ein Zielsystem oder einen Zielpfad. Bei der Nutzung von Erstellen/Website veröffentlichen lässt sich über das Kontrollkästchen Aktualisierbarkeit dieser vorkompilierten Site zulassen (Allow this precompiled website to be updateable) die Aktualisierbarkeit steuern. An der Kommandozeile kann das Werkzeug aspnet_compiler.exe verwendet werden. Der nachfolgende Befehl kompiliert den Inhalt eines Verzeichnisses im Dateisystem und speichert das Ergebnis in einem anderen Verzeichnis. aspnet_compiler -v -c -p H:\WWW\WorldWideWings\WebUI_CSVB\ H:\WWW\WorldWideWings\WebUI_CSVB_Compiled f -u

13 Übersetzungsvorgang und Verbreitung 35 In der nachstehenden Variante wird als Quelle ein IIS-Anwendungsverzeichnis verwendet. aspnet_compiler /v /LM/W3SVC/1/Root/WebUI_CSVB H:\WWW\WorldWideWings\WebUI_CSVB_Compiled f -u Die Option f bedeutet, dass ein eventuell vorhandener Inhalt des Zielverzeichnisses überschrieben wird. Die Option u steuert die Aktualisierbarkeit. Verbreitung von Anwendungen Aus den vorgenannten Kompilierungsoptionen ergeben sich nachstehende Optionen für die Auslieferung einer Anwendung (Deployment): Auto-Compilation: Die Anwendung wird komplett mit allen Dateien (auch den Hintergrundcodedateien und Dateien in /App_Code) auf das Zielsystem kopiert und dort beim ersten Aufruf übersetzt. Pre-Compilation: Es werden nur der Inhalt des /bin-verzeichnisses, die.aspx-,.ascx-,.asmx- und.asax-dateien, die.config-dateien sowie alle statischen Inhalte kopiert. TIPP Wenn Sie eine präkompilierte ASP.NET 2.0 / 3.5-Webseite aufrufen und dann nur die Meldung»This is a marker file generated by the precompilation tool, and should not be deleted!«sehen, haben Sie in der IIS-Konfiguration für dieses Web versehentlich die ASP.NET-Versionen 1.0 oder 1.1 ausgewählt. Nur ASP.NET 2.0 / 3.5 kann diese Dateien verarbeiten. Programmiersprachen An dem komplexen Kompilierungsvorgang können Sie bereits erkennen, dass nicht jede.net- Programmiersprache für ASP.NET verwendet werden kann, da neben dem Kommandozeilencompiler auch noch die Codegenerierung gewährleistet sein muss. Im.NET Framework 3.5 stellt Microsoft die Sprachen VB und C# zur Verfügung. Die ursprünglichen Pläne, auch C++ / CLI für Webprojekte zur Verfügung zu stellen, wurden nicht realisiert. Während in ASP.NET 1.x in Visual Studio nur genau eine Programmiersprache pro Projekt erlaubt war, kann ab ASP.NET 2.0 aufgrund der getrennten Kompilierung nun jedes Webform eine andere Sprache verwenden. HINWEIS Es ist aber nicht möglich, die Sprache innerhalb eines Webforms zu wechseln. Sofern in der.aspx-seite Inline- Programmcode zum Einsatz kommt, muss die dort verwendete Programmiersprache der in der Hintergrundcodedatei verwendeten Programmiersprache entsprechen. Der Programmcode in einem Webprojekt, der nicht an ein Webform gebunden ist (also alle eigenständigen Codedateien im /App_Code-Verzeichnis), kann im Standard weiterhin nur eine einzige Sprache verwenden. Hier gibt es aber die Option, Unterverzeichnisse (mit Namen VB, JS und CS) zu bilden, sodass mehrere Sprachen erlaubt sind. Diese Sprachmischung muss in der web.config-datei aktiviert werden. <codesubdirectories> <add directoryname="vb"/> <add directoryname="cs"/> <add directoryname="js"/> </codesubdirectories> Listing 4.3 Aktivierung der Programmiersprachenmischung in /App_Code

14 36 Kapitel 4 Das Webform-Programmiermodell Steuerelement-Typen Weiterhin existieren in ASP.NET zwei Typen von Serversteuerelementen: HTML-Serversteuerelemente und Webserversteuerelemente. Webserversteuerelemente sind die mächtigste Form der Serversteuerelemente. Ein Webserversteuerelement erkennt man an dem Namensraum asp, der vor dem Tag-Namen steht. <asp:label runat=server id="label1">bitte URL eingeben:</asp:label> <asp:textbox id="textbox1" runat="server"> <asp:button id="button1" runat="server" Text="OK"></asp:Button> HTML-Serversteuerelemente sind eine konzeptionelle Mischung aus den rein clientseitigen Standard- HTML-Elementen und den Webserversteuerelementen. Das Tag für ein HTML-Serversteuerelement entspricht einem normalen HTML-Tag, nur mit dem Zusatzattribut runat="server". Diese Steuerelemente besitzen eine serverseitige Ereignisbehandlung und können wie Webserversteuerelemente objektorientiert verändert werden. Sie erlauben auch die Datenbindung. Steuerelemente auf ASP.NET- Webforms HTML Client Control (keine Entsprechung in der FCL) z.b. <input...>, <textarea...> Server Controls (mit serverseitiger Ereignisbehandlung) [System.Web.UI.Control] Web Server Controls [System.Web.UI. WebControls. WebControl] HTML Server Controls [System.Web.UI. HtmlControls. HtmlControl] Einfache Controls z.b. Label, Button, Textbox Validation Controls z.b. RequiredFieldValidator, RangeValidator, RegularExpressionValidator Listen-Controls z.b. DataGrid, DataList Komplexe Controls z.b. AdRotator, Calendar Benutzerdefinierte Controls User Controls (.ascx-dateien) Custom Controls (C) Holger@Schwichtenberg.de 2002 Abbildung 4.8 Steuerelement-Typen in ASP.NET

15 Bestandteile eines Webprojekts 37 Es besteht eine 1:1-Abbildung zwischen HTML-Serversteuerelementen und HTML-Tags: Bei der Umsetzung der Seite erzeugt ASP.NET aus jedem HTML-Serversteuerelement genau ein Tag. Dazu ein Beispiel: <P id="hsc_text" runat="server">bitte URL eingeben:</p> <INPUT type="text" id="hsc_feld" name="hsc_feld" runat="server" value=" <INPUT type="button" value="ok" name="hsc_button" id="hsc_button" runat="server"> HTML-Serversteuerelemente unterliegen gegenüber Webserversteuerelementen folgenden Einschränkungen: Sie bieten keine Abstraktion vom Ausgabeformat. Ein HTML-Serversteuerelement wird immer auch als HTML-Tag ausgegeben. Es gibt kein Adaptive Rendering, also keine browserspezifische Ausgabe. Sie bieten keine Ereignisweiterleitung an übergeordnete Serversteuerelemente. Die Eingabefelder bieten keine Möglichkeit zum direkten Postback (kein AutoPostBack-Attribut). Lediglich Schaltflächen und (manche) Hyperlinks lösen einen Postback aus. HTML-Serversteuerelemente bieten aber auch drei Vorteile gegenüber Webserversteuerelementen: Die Migration von klassischem ASP- oder HTML-Code ist einfacher durch die 1:1-Abbildung zwischen HTML-Tag und HTML-Serversteuerelement. Visual Studio.NET unterstützt die Migration durch eine Konvertierungsfunktion im Webform-Designer (Kontextmenüeintrag Als Serversteuerung ausführen). Die Hinterlegung clientseitiger Skripte ist einfacher, weil es keine Umwandlung des Quellcode-Tags auf der Serverseite gibt. Es gibt einige HTML-Tags, die nur durch ein HTML-Serversteuerelement abgebildet werden können, weil es dafür (noch) kein Webserversteuerelement gibt. Komponentenart Basisklasse für HTML-Anwendungen Basisklasse für WML- und chtml-anwendungen Webserversteuerelemente System.Web.UI.WebControls.WebControl System.Mobile.UI.MobileControl System.Web.UI.HtmlControls.HtmlControl --- HTML-Serversteuerelemente Webbenutzer- Steuerelemente System.Web.UI.UserControl System.Web.UI.Mobile- Controls.MobileUserControl Tabelle 4.2 Basisklassen für die ASP.NET-Steuerelement-Typen Bestandteile eines Webprojekts Ein Webprojekt kann in ASP.NET 2.0 / 3.5 aus folgenden Elementen bestehen: Webforms (.aspx-dateien) mit zugehörigen Hintergrundcodedateien (.aspx.vb,.aspx.cs etc.) Webservices (.asmx-dateien) mit zugehörigen Hintergrundcodedateien (.asmx.vb,.asmx.cs etc.) Codedatei für globale Ereignisse (.asax) mit zugehörigen Hintergrundcodedateien (.asax.cs,.asax.vb etc.) Benutzer-Steuerelemente (engl. User Controls /.ascx-dateien) mit zugehörigen Hintergrundcodedateien für Webservices (.ascx.cs,.ascx.vb etc.) ASP.NET-HTTP-Handler (.ashx)

16 38 Kapitel 4 Das Webform-Programmiermodell Webform-unabhängige Codedateien im /App_Code-Verzeichnis (.cs,.vb etc.) /Bin-Verzeichnis für in dem Webprojekt referenzierte Assemblies und für die kompilierten Assemblies des Webprojekts Konfigurationsdateien (web.config) Datenbankdateien im Verzeichnis /App_Data Verzeichnisse /App_Globalresources und /App_localresources mit Ressourcendateien Verzeichnis /App_Browsers mit Informationen zu Webbrowsern Verzeichnis /App_Themes mit.css- und.skin-dateien Verzeichnis /App_Webreferences mit WSDL-Dateien und Proxy-Klassen Statische Inhalte (.htm,.gif,.pdf etc.) Mit Ausnahme des /App_themes-Verzeichnisses leitet der IIS die Inhalte der Sonderordner nicht direkt an den Client weiter. Der Inhalt dieser Ordner steht nur der Anwendung selbst zur Verfügung. Beim Anlegen der Sonderordner unterstützt Sie Visual Studio durch das Kontextmenü Add Folder im Projektmappen-Explorer. Einige Sonderordner werden auch automatisch durch andere Funktionen der Entwicklungsumgebung bzw. durch die webbasierte Konfigurationsschnittstelle von ASP.NET angelegt.